• ユーザが Block Kit interactive component (in Posts, Modals, Home tab) を操作したとき
  • → block_actions payload
• ユーザが Shortcut を使ったとき
  • → shortcut or message_actions payload
• ユーザが Slash command を送信したとき
  • → view_submittion payload
• ユーザが Modal を送信またはキャンセルしたとき
  • → view_closed payload

（これらのペイロードにはHMACの署名も付いている。）

Slackによって呼ばれるエンドポイントは以下の2つがある：

• Request URL: ユーザがアクションを起こしたときに呼ばれる。
• Options Load URL: select menu と multi-select menu のアイテムの読み込みに用いられる。使わなければ無指定でよい。

そして、ユーザのアクションに対して、アプリのエンドポイントは以下の反応ができる：

• Acknowledgement - （必須）アプリは3秒以内に 200 OK でレスポンスを返さなければならない（つまり時間のかかる処理は何らかの手法で非同期実行する必要がある）
• Message - メッセージの投稿または当該アクションが行われた投稿の書き換えを行う。これはペイロードに含まれる response_url に対してHTTP POSTすることによって行う。
• Modal - モーダルダイアログを開く。views.open APIを呼ぶ。
• Asynchronous - リクエストに対して直接的には何もせず、他のSlack APIを呼ぶ。

詳しい条件は忘れたけど、アプリによる投稿がアプリによって書き変えられた場合には「（編集済み）」のマークは付かない。

(追記: これからは 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 → … と直線的に進んでいきます。サーバは、あるクライアントから届いた編集の内容を、他のクライアント全員にも送信することで、皆が同じ文書の状態を共有します。

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

遅延による難しさ

リアルタイム共同編集が難しいのはネットワーク等による遅延があるからです。遅延があるため、すべてのクライアントが常に最新のリビジョンを見ているとは限りません。あるクライアントは、古いリビジョンの内容に基づいて編集を行い、それをサーバに送信するかもしれません。また、同じリビジョンに対して複数のクライアントが同時に編集するという競合も起きるでしょう。具体例としては以下のようなことが発生します：

• シナリオ (1) 「サーバ側の文書はリビジョン rev:53 なのに、クライアントBにはまだ rev:51 までしか同期されていなかった。このクライアントBが文書を編集し、rev:51 に対する編集操作をサーバに送った。しかしサーバ側は既に rev:53 である。どうやって辻褄を合わせればいいのか？」
• シナリオ (2) 「クライアントCは rev:74 に対して文字列の追加を行なった。この操作をサーバに送ろうとする最中に、サーバから（他のクライアントによる編集で生じた）rev:74→75 の編集操作が送られてきた。このとき、クライアントCが手元で rev:74 を編集したあとの状態と、サーバから送られてきた rev:74→75 の操作は、どうやって辻褄を合わせればいいのか？」

この問題を解決する手法がOTです。

リビジョンが分岐してはならない

同時編集の目標は「遅延がありつつも結果的には皆が同じ文書を共有する」ということです。つまりリビジョンは分岐してはならず、ただ1つの正統な本流だけが存在すべきだということです。

この観点で見ると、先述したシナリオでは、「本流のリビジョンからの枝分かれの発生」によって問題が生じていることが分かります。

解決方法:「競合する2つの操作を、順不同な直列操作に変換する方法を定義する」

逆にいえば、一時的に編集結果が枝分かれしても、それをすぐに本流の状態へと軌道修正できれば、ただ1つの本流を皆で共有することができます。

そのための要件として、まず、少なくとも、分岐が生じた場合にそれを直列に直せなければなりません。

(図はまだ)

「同じリビジョンに対する（つまり競合する）opAとopB」を、「opAをしたあとで、opBに相当するop B’ をする」に変換できなければならないのです。

また、それぞれの立場によって opA, opB の発生順序が違うので、「opAをしたあとで、opBに相当するopB’ をする」と「opBをしたあとで、opAに相当するopA’ をする」とが同一の結果になるという性質も必要です。

(図はまだ)

プレーンテキストでの具体例を示しましょう。同じリビジョンに対して「opA: 4文字目から10文字を削除する」「opB: 8文字目に “hello” を追加する」という競合する操作が生じた場合、これらは2通りの直列な操作に変換できます：

• opA→opB’の順の場合 「opA: 4文字目から10文字を削除する。→ opB’: 4文字目に “hello” を追加する」
• opB→opA’の順の場合「opB: 8文字目に “hello” を追加する。→ opA’: 4文字目から4文字を削除し、13文字目から6文字を削除する」

という直列な操作に変換することができます。いずれも同じ結果が得られます。

これが「操作変換 (OT)」です。このような操作変換が定義できれば、分岐の発生を修正して常に本流のリビジョンだけが存在するようにできます。

プレーンテキストにおける操作と操作変換の例

ここで一旦、プレーンテキストに対する操作を見ておきましょう。プレーンテキストに対する操作 (operation) は、以下の3つの基本操作の列として記述することが多いようです。

• insert(s) — 文字列sを挿入する
• delete(n) — n文字を削除する
• retain(n) — 既存のn文字を維持する

例えば、20文字の文書において、opA「4文字目から10文字を削除する」と、opB「8文字目に “hello” を追加する」いう操作は以下のように記述できます。

• opA = [retain(4), delete(10), retain(6)]
• opB = [retain(8), insert(“hello”), retain(12)]

そして、これを操作変換 transform(opA, opB) -> (opA', opB') すると以下が得られます。

• opB' = [retain(4), insert(“hello”), retain(6)]（opA→opB’ の順に適用する場合にopBに相当する操作）
• opA' = [retain(4), delete(4), retain(5), delete(6), retain(6)]（opB→opA’ の順に適用する場合にopAに相当する操作）

プレーンテキストの操作についての操作変換 transform(opA, opB) -> (opA’, opB’) の具体的な実装についてはここでは割愛しますが、プレーンテキストに関しては、それほど難しい処理ではありません。

また、上記の transform のほかに、2つの直列なopを合成する compose(op1, op2) -> op も定義しておきます。これも詳細は省略。

サーバ側での処理

サーバは以下の状態をもっています：

• 最新の文書（途中から参加するクライアントに配布する）
• 現在のリビジョン番号
• 過去に適用してきたopsの履歴（全てではなく直近のものだけ保持すればOK。保持する量を増やすほど遅延に耐えられるようになる）。適用時のリビジョン番号と紐付けて保持します。

サーバは、クライアントから編集操作が送られてくるたびに、次の処理を行います。（なおクライアントから送られてくるメッセージには、編集操作のほかに、クライアント側のリビジョン番号も含まれています。）

1. クライアント側とサーバ側とでリビジョン番号が異なる場合は、クライアント側から送られてきた op に操作変換を適用して、サーバ上の最新のリビジョンに適用できる op’ に変換します。具体的には、サーバ上にあるopsの履歴を用いて操作変換を必要なだけ繰り返します。例えばクライアント側が rev:30 でサーバ側が rev:33 の場合は、サーバに記録されている rev:31 から rev:33 までの3つのopsを相手にして、 opを3回transformします。これを op’ とします。
2. クライアント側とサーバ側でリビジョン番号が同一の場合は上記の変換は不要です。
3. 編集操作 op’ をサーバの文書に適用し、リビジョン番号をインクリメントします。また、op’ をサーバ上の履歴に追加します。
4. 編集操作を送ってきたクライアントにACKを返します。このACKには、サーバ上で確定したリビジョン番号を含めます。
5. その他の全クライアントに編集操作を反映させるため、op’ と最新のリビジョン番号を送信します。

クライアント側での処理

クライアント側は以下の状態をもっています：

• 現在の文書
• リビジョン番号（現時点でどのリビジョンまで同期しているかを表します）
• outstanding op（手元での編集によって一時的に分岐した操作のうち、サーバに送信済みだがまだACKが返ってきていないもの）
• buffered op（手元での編集によって一時的に分岐した操作のうち、送信待機中のもの）

クライアントでは、各イベントにおいて以下の処理を行います。

文書が編集されたとき

1. outstanding op がない場合は (=ACK待ち中でない場合は)、編集操作 op を outstanding op にセットしつつ、サーバに送信します。
2. outstanding op がある場合は (=ACK待ち中の場合は)、buffered op に op をセットして送信待ちにします。buffered op が既に存在する場合は、その buffered op に op を合成します。

ACKが返ってきたとき

1. ACKに含まれる revision番号で手元のリビジョン番号を更新します。
2. outstanding op を空にします。
3. buffered op がある場合は、それを outstanding op に移しつつ、サーバに送信します。

opを受信したとき

1. outstanding op がある場合は、(outstanding_op, op') := transform(outstanding_op, op) という更新をします。
2. さらに buffered op がある場合は、(buffered_op, op') := transform(buffered_op, op') という更新をします。
3. outstanding opもbuffered opもない場合は、opをそのまま使います（つまり op' := op とします）。
4. クライアント側の文書に操作 op’ を適用します。

おわりに

実用的なテキストエディタを作る場合は以下のようなトピックも検討しなければいけない気がします。

• カーソルの動きもOTの対象にする
• operation をベースにしたUndo/Redoの実装
• サーバ側でどのようにスケーラビリティを得るか
• HTML5 の contenteditable と日本語IMEによって発生しそうな地獄との戦い

参考文献

• http://operational-transformation.github.io

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

マウス周りは、AppleのMagic Trackpad 2をキーボードの真横に置いて使っている。ただしそのままだとトラックパッドとキーボードの高さがまったく合わなくて辛いので、簡単なスタンドを設計して3Dプリントしてトラックパッドを底上げした。これで十分に使いやすくなったけど、トラックパッドはキーボードより更に高くしてもいいかもしれない。

トラックボール（中指）も好きだけど、トラックパッドのほうが用途を選ばないかなと思っている。例えばPhotoshopみたいな操作をトラックボールでやるのは自分は苦手だ。

キーレイアウトに関して慣れない点

• Macの純正キーボード (US配列) と比べてCommandキーが親指から遠い位置にあって押しにくい。この点を考えるとmicro82ではなくmicro84のほうが良かったかもしれない。
• 最右列（Home, End PgUp, PgDnとか）が邪魔に感じる。

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

なぜ買い替えたのか理由を色々と書いたのだけど、うっかり消してしまったので写真だけ貼っておく。手短に言えば「安くて軽いフライパンをIHで使うとすぐに反り返ってストレスMAXになる」ということです。

火の通りもテフロン加工もすごく良いです。大事に使おうと思う。

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

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

主要なWebhooksとしては以下がある：

• Webhooks for Pages — Facebookページ上での各種アクティビティをリアルタイムに知れる。
• Messenger Platform - Webhook — Facebookページの受信箱のアクティビティをリアルタイムに知れる。
• Webhooks for Instagram — Instagramアカウント (Business/Creatorのみ) へのコメントやストーリーズ終了時のInsightsをリアリタイムに得られる。

それぞれに必要なパーミッションとその審査について簡単にまとめておく。

Webhooks for Pages

Page関係のWebhookを使うには、該当するオブジェクトを扱うパーミッションを取得して、なおかつライブモードで動作させる必要がある。それまでは開発者用のAppダッシュボードから送れるテストメッセージしか受信できない。

例えばページの投稿に付いたコメントをWebhookで知りたい場合は pages_read_user_content パーミッションが必要になる。（ちなみに以前は manage_pages と publish_pages という2種類のパーミッションしか存在しなかったが、API v7.0から細分化されたらしい）。

Facebookログインを一切使わないアプリを申請するときは、アプリが “Server-to-server App” であることをレビュアーに伝える必要がある。とくにWebhookだけを使うアプリはレビュアーに趣旨をうまく理解してもらえないことがある。申請がどうしても却下される場合は、Webhookの利用ではなく、サーバからPages API呼び出しを行う様子をスクリーンキャストとして撮影して申請するといいかもしれない。

Messenger PlatformのWebhook

Messenger Platformを使うには page_messaging パーミッションが必要になる。このパーミッションがない場合は、開発モード／ライブモードを問わず、管理者によるアクションに対してしかWebhookが送信されない。

page_messaging パーミッションの申請は簡単で、簡単なスクリーンキャストを撮影して送るだけでいい。Messenger PlatformはWebhookの利用が前提なので、レビュアーにWebhookの話が通じないという難しさもない。

審査の過程でテストメッセージが送られてくるので、それをちゃんと受信しておき、2日以内にSend APIを使って適当な返事をする必要がある。

Webhooks for Instagram

InstagramのWebhooksは、自分のInstagram Business/Creatorアカウントでの利用であれば審査なしでも使えるようだ（そういう仕様なのか、それともたまたま使えているだけなのかは分からない）。

これは次のようにする：

• Facebookページと対象のInstagramアカウントをリンクする
• Facebook Appの開発者をページの管理者にする
• Facebook App内にInstagramのAppを作る
• InstagramのWebhooks用エンドポイントを設定する
• 対象のInstagram Business/Creator アカウントを、アプリのテスターとして追加する

これでWebhookが飛んでくるようになる。

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

処理の要点は、メールの自動受信処理、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

Cloud Functionsでの処理はPythonで書いた。

1. 複合機からメールを送信する

大抵のFAX複合機には、受信したFAXをPDFにしてメールで送信する機能がついている。これを使って受信データを外部に送信する。

次に、複合機から送信されたメールを何らかの方法で自動で（機械的に）受信する必要がある。今回はそれを SendGrid Inbound Parse Webhook を使って行うことにした。

2. メールを受信する

複合機から送信したメールをSendGrid Inbound Parseに受信させる。受信したメールはparseされて、HTTPリクエストとしてGoogle Cloud Functions (のHTTPトリガ) に送られる。

3. Google Cloud FunctionsでFAX (PDF) を処理する

Google Cloud Functionsで、メールヘッダや添付PDFファイルを受け取って、以下の処理を行う。

3.1. Google Cloud VisionでOCRする

Cloud Visionの DOCUMENT_TEXT_DETECTION を使ってOCRを実行する。手書き文字も認識される。

• ページはPDFの1〜5ページ目のみを読み取るようにした。
• languageHintsには[‘ja’]を指定した。

3.2. PDFの向きを直す

FAXはひっくり返った向きで送られてくることが多いし、横長で印刷された文書というのもたまにある。

向きを直しておかないと見づらいので、OCRの結果をもとにページの向きを判定して、PyPDF2を使ってPDFの各ページを回転させる。

3.3. Google共有ドライブ (G Suite) にアップロードする

GoogleのDrive APIを使ってGoogle DriveにPDFをアップロードする。

PythonでGoogleのサービスのAPIを呼ぶには、googleapiclient (google-api-python-client) を使う。

G Suiteの共有ドライブにアップロードする場合は、driveIdや、supportsAllDrives=Trueなどを指定しないとうまく動かない（後者はそのうちに撤廃されるらしいが）。このへんの「共有ドライブ」周りについてはDrive APIの英語ドキュメントもまだちゃんと整備されておらず、ググらないと分からなかった。

3.4. 文書のサマリーを作る

文書の形式によっては、OCR結果にノイズ的な文字列が多く含まれることがある。そのままだと読みにくいので、情報として価値のない文字列や、罫線を文字として誤認識したものや、日本語/英語/中国語(漢字)以外の謎の言語として誤認識されたものは、除去したほうがいい。OCR結果の各要素に含まれる confidence の値なども参考にする。

本気でやるなら、罫線は画像処理系のアルゴリズムを使ってあらかじめ除去したほうがいいかもしれない。

Cloud Visionが返す結果は pages → paragraphs → words → symbols という構造になっている。この構造をトラバースして、書式を整えたり、不要部分を除去したりしながら、結果の文字列を組み立てる。

3.5. 文書のタイトル抽出する

OCRの結果をいろいろとルールベースで処理して、タイトルっぽいものを抽出する。

文字列の長さや、文字列が占める面積、タイトルによくある表現（について、のお知らせ、件名〜、etc.）等々を基準にスコアリングして判定している。

抽出したタイトルを用いて、Google Driveに先ほどアップロードしたファイルをリネームする。

3.6. Slackへ投稿する

Slack APIのchat.postMessageを使って、以下のものをSlackに投稿する。

• 抽出タイトル
• Google DriveのプレビューURL (webViewLink)
• OCR結果のサマリ文字列

送信元FAX番号やOCRで得た内容に基づいたルールセットで投稿先のチャンネルを変えるようにしている。

SlackにはGoogle Driveの公式Appがインストールされているので、Drive上のファイルのURLを投稿するだけで自動的にunfurl（プレビュー展開）される。ただしこれを機能させるには、Botユーザではなく、Google Driveへのアクセス権をもつ一般ユーザとしてURLを投稿する必要がある。

評価

• 良いときは複合機がFAXを受信してから5〜10秒くらいでSlackに投稿される。しかしCloud FunctionsがColdスタートした場合は受信から投稿まで10〜15秒くらいかかってしまうこともまれにある。
• しばらく運用しているが、エラーでFAXをとりこぼすということは起きていない。

Amazon SES (の受信機能)

https://aws.amazon.com/jp/ses/pricing/

• 受信は1000通/月まで無料。以降は0.10USD/1000通。これに加えて256Kバイトのチャンク（端数切り捨て）について0.09USD/1000チャンク。
• （送信は0.10USD/1000通。添付ファイルは0.12USD/1GB）
• 圧倒的に安い一方で、機能は最もプリミティブ

受信のレイテンシの低さは申し分ない。メールがAWSのSMTPサーバに到達した1〜3秒後にはS3に格納される。

AWSの中で使うのは楽だが、AWSの外に受信データを渡したい場合はAWS LambdaやAmazon SNSを使ってその仕組みを作る必要がある。

Twilio SendGrid (のInbound Parse Webhook)

https://sendgrid.com/pricing/

• 受信 (Inbound Parse Webhook) は無料プランでも使える
• 有料プランは、14.95USD/mo (40000通/mo = 0.373USD/1000通) から
• （送信は無料プランだと100通/day）
• （マーケティングメール向けの機能/プランもある）

遅延問題 (今は解決）

トライアル契約でParse Webhookを使ってみたが、レイテンシが使い物にならないくらい大きくなることがあった。良いときはメールを送ってから数秒でWebhookが呼ばれるが、悪いときには30〜60分以上の遅延が（しかも少なくない頻度で）発生した。

念のために有料プラン (Essentials 40K) を契約して数日置いてから試してみたが状況は変わらなかった。

サポートに報告したら、数日後にチケットに “degraded” という印が付いたが、返事はまだこない。

2020-06-02追記： SendGridのサポートからようやく返事が来て、この問題は解決したとのこと。コロナ禍で対応が遅れたのだろうか。

Mailgun (のInbound Routing)

https://sendgrid.com/pricing/

• 受信 (Inbound Routing) は有料プランユーザのみ使える。
  • 最安のプランが高い: 35USD/moで送信50000通/mo = 0.7USD/1000通
• 受信自体は無料で、そのあとの転送 (HTTP POSTも) にチャージされる。
• （メール送受信自動化用プラットフォームとしては高機能）
• （マーケティング担当者向けの機能はない）

試用はしていない。

Mailjet (のParse API)

https://sendgrid.com/pricing/

• 受信 (Parse API) は有料プランユーザのみ使える。
• 最安の有料プランは8.69USD/moで30000通 = 0.289USD/1000通
• （マーケティングメール向けの機能もある）

試用はしていない。

Mailchimp Transactional Email (旧Mandrill)

https://mailchimp.com/pricing/transactional-email/

• Mailchimpの有料プラン (10.62USD/mo〜) に入らないと使えない
• 送信コストが高い (20USDで20000通 = $0.8/1000通)

試用はしていない。

その他

ドキュメントを見ても受信機能の詳しい仕様が書かれていないサービスが多かった。送信がメインで、受信機能はあくまでおまけという位置づけであることが多いのだろうか。

この種のメールサービスは悪用防止のために、試用ユーザや新規契約ユーザに一定の制限をかけることがあるそうなので（しかもその内容は明示されていないので）、試用中に評価を行うのが難しいと感じた。

AWS Lambdaと比べて

Cloud Functionsの特徴としては：

• HTTPトリガー（要するにWebhook）が最も基本的なトリガーである。
  • 汎用的な仕組みなのでロックインされにくい。
  • 外部サービスなどからのWebhook連携がシンプルに実現できる。HTTPエンドポイントを別途に設定しなくていいので、構成がシンプルだし、ロックインも軽減できる。
• 使える言語: Python 3.x, Node.js, Go, (近日サポート？: Ruby, Java, PHP)
• Pythonの場合は：
  • 依存パッケージは、pipのrequirements.txtに書いておくだけでインストールされる。
  • HTTPトリガの処理にはFlaskが使われる。

AWS Lambdaと比べて、簡便であることを重視している印象を受ける。

Functionを作る

基本的には公式ドキュメントのYour First Function: Pythonの通りにすればいいので、そこに載ってないことだけ書いておく。

Functions Frameworkを使う

最近になってFunctions Frameworkというライブラリが用意されたようだ。これは、実行環境（ローカル環境 / Cloud Functions / Cloud Run）を選ばずに、Functionを実行するためのもので…といっても大げさなものではなくて、例えばPython版の場合は単にFlaskやGunicornによる実行を遮蔽しているに過ぎない。

Functions Frameworkを利用して、Functionを作ってみる。

$ pip3 install functions-framework -U

main.py

def hello(request):
    return "Hi"

requirements.txt

# 今回は空っぽ

そして以下のように実行すると、Flaskアプリケーションとして実行される：

$ functions-framework --target=hello --debug

Functionをデプロイする

以下のコマンドでデプロイできる。デプロイを上書きする時も同じ。

$ gcloud functions deploy <name> \
    --project <project-name> \
    --region=asia-northeast1 \
    --runtime=python37 \
    --entry-point=hello \
    --trigger-http \
    --allow-unauthenticated

ここでは以下を指定している。

• リージョンはasia-northeast1（東京）
• ランタイムはPython3.7
• トリガはHTTP
• 認証なし

デプロイには1分くらいかかる。

他のGoogle Cloudサービスを呼ぶ

作ったFunctionから他のGoogle Cloudサービスを呼ぶには当然ながらCredentials（認証情報）が必要になる。Cloud Functionsにおいては、環境変数GOOGLE_APPLICATION_CREDENTIALSを明示的に設定していない限り、デフォルトのCredentialsが自動的に取得される（内部的には、公式ライブラリがMetadata Serviceから取得してきてくれるっぽい）。

https://google-auth.readthedocs.io/en/latest/reference/google.auth.html#google.auth.default

この仕組みによって、コードベースなどにCredentialsを入れることなしに、他のGoogle Cloudのサービスを呼ぶことができる。例えばCloud Visionを使いたいなら、以下のようにするだけでいい。

client = vision.ImageAnnotatorClient()

Credentials自体が必要なときは、google-authモジュールを使えばいい。

import google.auth
(creds, _) = google.auth.default(scopes=["https://www.googleapis.com/auth/drive"])
drive_service = build("drive", "v3", credentials=creds)

データストア / 永続化

これはどうすればいいのかまだ考えていない。「ちょっとした自動化」程度のアプリケーションを除けば、多くの場合に、状態を保存するための場所が必要になる。Cloud Firestoreが最も手軽だろうか。

デプロイ後の監視など

エラー追跡

• 標準の仕組み： 発生した例外は Cloud Error Reporting に集積される。
  • ただし通知はメール通知のみ
• Sentryなどのサードパーティのエラーモニタリングサービスのほうが高機能
  • サーバレス環境用のPythonデコレータが提供されている。
  • Slackへの通知などもできる

ロギング

• 標準の仕組み： 以下は Cloud Logging に記録される
  • stdout, stderrへの出力
  • Cloud Logging ライブラリによるログ出力（Pythonのloggingモジュール用のハンドラあり）
• 用途によってはPapertrailやlogDNAといった、ログをLive tailできるサービスも便利かもしれない（これらにはPythonのloggingモジュール用のハンドラもある）

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

• 格安VPS事業者がロードバランサを提供していなくても使える
• 格安VPS事業者のあやしいロードバランサより優れている（かも）
  • ヘルスチェックの結果をちゃんとメールしてくれる
  • 信頼性が高そう、おかしな挙動が少なそう
  • 高速フェイルオーバー（後述）ができる。
• そこそこ安い:
  • Origin2つまでは $5/mo
  • Originを1つ増やすごとに +$5/mo
• 2019年末に “Zero-Downtime Failover” という機能が実装された（有料プランのみで使える）。リクエストを送ろうとしたOriginがダウンしていた場合に、別のOriginに1回だけリトライしてくれる。つまりヘルスチェックによる死活監視を待たずに即座にフェイルオーバーが行われる。

短所としては：

• Cloudflareを経由するのでリクエストのRTTが10~25ms程度増える。これが問題になるかどうかは用途による。
• HTTP/S以外には使えない
• WebSocketを使う場合、同時接続数の許容値がよくわからない。

あと、もちろん、グローバルな負荷分散が行えるとかのメリットもあるけど、ここでの文脈では関係ない。

Zero-Downtime Failover

これはウェブのリバースプロクシによくある機能で、例えばnginxのproxy_next_upstreamのようなものだ。Cloudflareでは次のように機能する:

A/AAAAレコードが複数用意されている場合またはCloudflare Load Balancingを使っている場合に、1つ目のOriginに対するリクエストでそのOriginが落ちていたら、2つ目のOriginに対してリトライする。このリトライは1リクエストについて1度だけ行われる。

これによってヘルスチェックを待たずに即座にフェイルオーバーできる。Cloudflareのヘルスチェック間隔は60秒（課金すると15秒まで縮められる）と結構長いので、これ重要。

ちなみに、この機能は2019年末ごろに追加されたようで、CloudflareのFreeプランでは使えず、有料プランのみで使える。

このZero-Downtime Failoverは、特に何も設定しなくても自動で行われるはずなのだけど、自分は以下のワナにはまって上手く動かなくなっていた。

Zero-Downtime Failoverが機能しなくなるワナ

Load BalancerのPoolにOriginサーバを列挙する際に、IPアドレスではなくホスト名でOriginsを指定するとZero-downtime Failoverが機能しなくなる (2020年4月末時点)。

Nature Remo E lite

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

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

Nature Remo E lite は、元々は2020年3月に発売される予定で、自分は2月の初頭に予約してあったのだけど、けっきょく4月末になって発売されて、今日ようやく届いた。

東北電力でのBルート開通手続き

スマートメータと電力使用者のHEMS機器とのあいだの通信のことを「Bルート」と呼ぶらしい。Bルートサービスを利用するには、電力会社に申請してIDとパスワードを得る必要がある。

東京電力などではウェブから申請できるらしいが、（2020年4月時点で）東北電力にはそういう仕組みが無いので、書面で申請することになる。

自分の場合は、Webで検索すると出てくる「Bルートサービス利用申込書」という書類を印刷して、担当地域の営業所に郵送した。1週間後くらいにIDとパスワードが書かれた紙が郵送されてきた。

セットアップはこんな感じ

1. Remo E liteをコンセントに指す。
2. Nature Remoアプリを開いて、デバイス登録 → Remo E liteを登録
3. Wi-Fiのパスワードを入力する。
4. BルートのIDとパスワードを入力する（BルートのIDがけっこう長くて入力が面倒）。
5. 何も表示されないなーと思いつつ3分くらい待っていると情報が表示された。

アプリの画面はこんな感じ：

使用感など

• 現在の電力値が表示されなくなることがたびたびある。スマートメータとの通信がロストしてるっぽい？
• スマートメータとの通信状況（通信がうまくいってるかそうでないか）がよく分からない。
• アプリがまだまだ未成熟という感じで必要最小限の機能しかない。グラフ表示の日付切り替えの動作がおかしい。まだ発売されたばかりなので今後のアップデートに期待。
• 家全体の合計消費電力がわかるだけ（＋グラフとして残るだけ）なので、これがどれだけ役に立つかはまだ分からない。

APIも使えるらしいが

情報取得用のAPIもあるみたいだけどまだ試してない。

スマホでシネマティック撮影

今回Osmo Mobile 3を買おうと思ったのは、こういう動画を見てちょっと衝撃を受けたため。

スマホのレンズなので、ボケなどの表現は難しいし、暗所には弱いけど、それでもこれくらいの動画が撮れるならかなり使い道があるなと思った。

実はこの種の3軸ジンバルは、平行移動方向の揺れ（たとえば歩行による揺れ）を吸収するのが苦手らしいのだけど、最近のスマホに付いている光学式手ブレ補正と組み合わせることで、その点もある程度補えるようだ。

開封＆初使用

開封の様子も一応撮っておいた。

そして、近くの神社に行って初めて使ってみて撮れた動画がこれ。

この程度の安定性が限界ということはまったくなくて、あくまでも初めて使ってサンダル履きで適当に歩いてもこれくらいになるというもの。滑らかな歩き方とかスタビライザーの構え方を練習すれば、もっと上手に撮れると思う。

良い点

数年前にもこういう電子ジンバルに触れてみたことがあるけど、それとは比べ物にならないくらい良くできている。

• バッテリーがかなり持つ（公称10時間以上？）
• バッテリー内蔵でUSB Type-Cで充電できる
• 値段がとにかく安い
• スマホアプリとジンバルが通信して連携する
• そこそこコンパクトに折り畳める

いまいちな点

• チルト方向（いわゆる上下）の可動域がちょっと狭いので、通常の持ち方からぶら下げ撮影にシームレスに移行できない。

(3月30日) 予定通り実施の告知

3月31日に日本無線協会から「無線従事者試験の実施について」という書面が届いた。内容としては、4月4日と5日の１アマと２アマの試験は予定通り実施するということと、今回の受験を取り止めたい人には、次回の試験への振替または受験料の返還に応じるというものだった。

(3日19時) 産経新聞が記事を出す

中止の決定が行われる前の3日19時過ぎに産経新聞がこんな記事を出した。偶然にもブラウザのレコメンド検索機能にこの記事がひっかったので、自分も20時くらいに読んでいた。

週末のアマチュア無線の国家試験実施へ 国の方針に批判も [産経ニュース 2020-04-03 19:12]

一部を引用しておく：

新型コロナウイルスの流行を受け、東京都などが不要不急の外出自粛を呼び掛け、民間の小売店なども営業を中止するなど、感染拡大防止への取り組みが広がる中、主に趣味のための同試験を実施する国の方針には批判も上がりそうだ。

（中略）

ただ、受験予定者の中からは「アマチュア無線は不要不急の資格で、中止すべきだ」との声も上がる。試験時間は１日計５時間と長く、閉鎖空間に多くの人が集まるため、感染拡大のリスクが高まるためだ。

(3日23時) 試験中止の連絡が来る

試験前日の夜23時過ぎになって日本無線協会の担当支部から中止を知らせるSMSが届いた。

なぜSMSで？と思いつつ、念のために日本無線協会のサイトを見に行ったら、（かなり目につきにくい場所に）中止のお知らせが書いてあった。

自分が申し込んだ試験地はいつも受験者が少ないようなので、感染リスクを気にする感じでもなかった。ただ、東京会場はどうやら百人以上受験するそうなので、中止になること自体は仕方ないと思う。もちろん前日の深夜にドタキャンというのはひどいと思うのだけど。

(4日0時) 試験中止を伝える記事が出る

中止決定を受けて、深夜にこの記事が出た。

アマチュア無線の試験、急遽中止に　受験者への通知間に合わず [産経ニュース 2020-04-04 00:49]

追記: その後の手続きについての書類 (4月6日付) が届く

日本無線協会から封書が届いた。内容は、9月期への振替受験または受験料返金のための書類をまだ提出していない人は提出してくれということと、当日に試験地に来てしまった人には交通費や宿泊費を補償するというものだった。

84円切手付きの返信用封筒も同封されていた。

おわりに

受験すればまず落ちることはないだろうと思っていたので、けっこうガックリきた。

次の試験は9月末… とりあえず3級とかを取るという選択肢もあるかもしれないけど、3級の試験もいつ再開されるのか分からない状況だ。

気づいたら試験日（4月4日）まで残り40日余りになってしまっていて、今回はパスすべきかとも思ったが、思い切って受験申請日ギリギリで申し込んだ。

いまのところ工学問題の入門書を１冊買ってざっと目を通すことしかしていない。しかしこの本は網羅性がいまいち良くなさそうなのと、最新の版が2012年なので新しい問題に対応できていない。特にここ数年で問題の傾向が変わっているらしいので、この本だけに頼るのはまずそう。

法規問題に関しては手を付けてすらいなかったので、法規問題が載ってる参考書を追加で１つ買った。見た感じ覚えることはそれほど多くなさそう。ただし、いかんせん入門者なのでモールス符号とかQ符号とかはゼロから覚えないといけない。

暗記系の事柄についてはAnkiを使うことにした。AnkiはいわゆるSRSというもので、出題頻度を自動調整してくれる暗記カードといったもの。iOS/Android版（有料）もある。

というわけで以下のような感じで勉強をやり始めた：

• 参考書２つ
  • 基礎からよく分かる無線工学
  • 第1級ハム集中ゼミ
• 過去問ベースの工学問題解説サイト: 無線工学を基礎から学ぶ - 第１級アマチュア無線技士
  • このサイトは素晴らしい。過去問ベースなので工学はここだけ見てれば大丈夫そう。
• 暗記系はAnkiにデッキを作って、やる
• 過去問PDFをやる（特に法規）
  • iPad/macOSのNotabilityというアプリにPDFをつっこんだら何だかいい感じになった。

単に試験に合格するだけなら実際の問題を解きまくればいいのは分かりきっているので、そういう勉強は好きではないけど、今回は効率重視でやることにした。

インコのケージの前に置くお立ち台。これでケージの出口からそのまま歩いて出てこれるようになる。

https://github.com/ciscorn/starlette-graphene3

Subscriptions (via WebSocket) にも対応させてある。

Starletteは標準でもGraphene v2のサポートを備えている (starltte.graphql) のだけど、このGraphene v2は内部で graphql-core-legacy という古いライブラリに依存しているため、文字通りレガシーなものになってしまっている。

次期Graphene v3の土台になっている graphql-coreは、Python 2を切り捨ててasyncioネイティブに書き直されているので、非同期処理が簡潔に実装されていて、非同期のWebフレームワークやsubscriptionsに容易に対応できる。

無線の入門書を読んでいたら「伝送線路のインピーダンス」とか「アンテナのインピーダンス」とか「自由空間のインピーダンス」とかいう概念がしれっと出てきた。インピーダンスというと電気回路のインピーダンスしか聞いたことがなかったので、ろくな説明もなく出てきて頭が混乱したのだけど、調べてみると電磁波の話のようだ。

つまり、（特に高周波のときには）電流を実際に伝えているのは導体や誘電体に沿って伝搬する電磁波であり、伝送線路やアンテナを扱うときはこの電磁波の振る舞いを考えないといけない…ということらしい（？）。波なので反射するし、電磁波なので空間中に放射されたりする。

ただし、例えばアマチュア無線レベルの試験問題なんかだと、この辺については『理解なんてしなくていい。初歩的な事実と数字だけ覚えておけばいい』みたいな扱いになっているので、試験とかのために体系的に理解する必要はまったくないようだ。

…とはいえ理工学的な興味として、いずれはちゃんと理解できるようになりたい。

資料

このへんの話題は電波や高周波回路を扱う場合 (この領域をRFっていうらしい) にのみ要求されるので、電気/電子回路のふつうの入門書にはまず載っていない。

そのなかで、CQ出版社のサイトで検索して見つけたこの本は良いかもしれない。

• 電子回路設計のための電気／無線数学

この本の目次を眺めてみるに、やはり電気回路(電子回路)をやるなら周波数ドメイン（フーリエ変換、ラプラス変換）の感覚が必要で、さらにRFをやるなら電磁気学とかベクトル解析もやりましょうという感じなのかなと思う。

ベクトル解析

電磁気学をやるには、まず初歩的なベクトル解析の感触をつかんでおかないといけない。

• grad, div, rot, ▽の基本的な定理: https://eman-physics.net/math/vector02.html
• ガウスの定理: https://eman-physics.net/electromag/gauss.html
• ストークスの定理: https://eman-physics.net/electromag/stokes.html
• 平面のグリーンの定理
• スカラーポテンシャル、ベクトルポテンシャル
• https://ja.wikipedia.org/wiki/四元数（ここまでやらなくてよさそう）

今まで全く触れたことがないけど、初歩的な定理を使うだけならそれほど難しくないのかもしれない。

電磁気学

日本のWikipediaはあまり良くないのだけど、キーワードだけ並べておくと：

• https://ja.wikipedia.org/wiki/マクスウェルの方程式
• https://ja.wikibooks.org/wiki/電磁気学/電磁波の式の導出
• https://ja.wikipedia.org/wiki/伝送線路
• https://ja.wikipedia.org/wiki/電信方程式
• https://ja.wikipedia.org/wiki/波動方程式
• https://ja.wikipedia.org/wiki/特性インピーダンス
• https://ja.wikipedia.org/wiki/電磁場解析
• https://ja.wikipedia.org/wiki/FDTD法
  • Understanding the FDTD Method ←これ面白そう
• https://ja.wikipedia.org/wiki/境界要素法
• https://ja.wikipedia.org/wiki/表皮効果

BJT

• 矢印はEmitterにつける
• 矢印は電流の方向を示す
  • NPN: B→E（C→E）
  • PNP: E→B（E→C）

FET

MOSFETとJFETについて。

一部の製品を除いてFETに極性はなく、電流の方向に基づいて便宜的にソースやドレインと呼んでいるに過ぎない。

ただしディスクリート型3端子のMOSFETでは、ボディ（a.k.a. バックゲート）とソースが内部的に接続されているので、ソースとドレインを区別する必要がある。つまり極性がある。

• N-channelのFETは、ゲートの電位を上げるとドレイン→ソース電流が流れる。
• P-channelのFETは、ゲートの電位を下げるとソース→ドレイン電流が流れる。

MOSFETは、プロセスに応じて、エンハンスメント型、デプレッション型の両方が作れる。

JFET

ゲートの矢印は、チャネルを開けるための電圧の印加方向を示している。

JFETはデプレッション型。

MOSFET

• バックゲートの矢印は、寄生ダイオードの方向を示している。
• ディスクリート型3端子のMOSFETはソース-バックゲート間が結ばれている。回路図記号でもそれが表現されている。

なんだか、すごく間違ってる気がする。

（以下正しいのかどうか分からない）

線形回路は、次の連立一次方程式で表現できる。（電流源を含む場合はダメ？）

$$Z \boldsymbol{i} = \boldsymbol{v}$$

これは次のように変形できる：

$$Z \left(\begin{matrix} \frac{1}{a} & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & \ddots & 0 \\ 0 & 0 & 0 & 1 \end{matrix}\right) \left(\begin{matrix} a & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & \ddots & 0 \\ 0 & 0 & 0 & 1 \end{matrix}\right) \boldsymbol{i} = \boldsymbol{v}$$

左辺の右側（下式）は、電流 $i_1$ の大きさをa倍することを意味する。

$$\left(\begin{matrix} a & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & \ddots & 0 \\ 0 & 0 & 0 & 1 \end{matrix}\right) \boldsymbol{i}$$

左辺の左側（下式）は、電流 $i_1$ が流れるエッジにあるインピーダンスの大きさを$\frac{1}{a}$倍することを意味する。

$$Z \left(\begin{matrix} \frac{1}{a} & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & \ddots & 0 \\ 0 & 0 & 0 & 1 \end{matrix}\right)$$

これらが意味するのは、電流 $i_1$ が流れるエッジだけを見たときに、電流 $i_1$ の大きさと、そのエッジ上にあるインピーダンス $z_1$ の大きさは反比例の関係にあるということだ。

$$z_1 i_1 = \text{const.}$$

const.の項は起電力や電圧降下の和を表しているとすると、この式は上図の等価回路を表現していることがわかる。

$$ Z_{eq} I = V_{eq} - V $$

つまり：

$$ V = V_{eq} - Z_{eq} I $$

プロットの内容は、1次元と2次元の波動方程式を最も単純なやりかたで数値シミュレーションしてるだけ。

matplotlibのAPIは元々いまいちわかりにくいのだけど、3Dプロット周りとかアニメーション周りのAPIは更にわかりにくい。

２次元：

こっちは１次元。つまらない。

Pythonのコードは以下の通り。もっと効率的に計算できるだろうけど、安直にやっている。

どっかにキャッシュでも残ってないかなと思って検索してみたら、wonderflのコードを律儀にアーカイブしてくれているサイトを見つけた。

• http://wa.zozuar.org/user.php?name=wanson
• http://oreorekaihatsu.blogspot.com/2017/06/wonderfl.html

こんな感じ：母音音声（あいうえお）の合成、2次元の波紋、鳥や魚の群れの動き(Boid)、ロボットアーム、反射と屈折、揺れる謎の物体。

ところで今だったら、こういう可視化＋インタラクティブ性みたいなものって何で作ると筋がいいんだろうか。

カジュアルな用途なら、どう考えてもWeb技術だろう。つまりCanvas, SVG, WebGL, WebAudio, (WebGPU?), etc. を直接使うかライブラリ経由で使うかだ。ブラウザでページを開くだけで動くのは最高だし、Electron製とかのアプリでも使える。

しかしそこで、他の言語と相互運用したい欲求が生じる。具体的にいえば、内部的な計算の部分はPythonで書きたいとかだ。

Pythonに Bokeh というライブラリがある。Pythonからデータを供給して可視化だけWebブラウザで行うというものだ。BokehはWebSocketを使ってPython-JS間でデータをやりとりする仕組みらしい（WS周りはtornado）。

手元の可視化で使うだけならこのアプローチでいいだろうけど、Web上で公開するとなるとPythonのサーバを立てなければならなくなる。

WebAssemblyを使うという手もあるだろうけど、カジュアルさはかなり低下しそう。

関係ないけど、こんなライブラリも見つけた：

• https://github.com/maartenbreddels/ipyvolume/

モリサワパスポートには大量のフォントが収録されているのだけど、その中には単なる収録文字セットの違い (Std, Pro, Pr5, Pr6など) によるvariantsも数多くある。例えば以下のような感じだ：

• A-OTF リュウミン Pro (Adobe Japan 1-4)
• A-OTF リュウミン Pr5 (Adobe Japan 1-5)
• A-OTF リュウミン Pr6 (Adobe Japan 1-6)
• A-OTF リュウミン Pr6N (Adobe Japan 1-6, JIS新字形)

これらのvariantsが統制なく使われると、結局、データをやりとりする全員がすべてのvariantsをインストールしなければならなくなる。これを避けるために、なるべく最小限のvariantsのみが使われるようにしておきたい。

具体的な方針としては…

• スーパーセット（例: Pr6N）のファミリが存在するなら、サブセット（例: ProN）のファミリは捨てる。つまり常にスーパーセットを使うようにする。（大きめの文字セットを使うと計算資源も食うようだけど、問題ないだろう）。
• 字形の違い（例: ProとProN）があるものについては、新字形のみを保持する。
• ついでにフォルダ分けもしておく： フォントファミリ名でフォルダ分けする。つまり、同じファミリ名のサブファミリ違いを、同一のフォルダにまとめる。

…という感じにしようと思う。さすがにこれを手動でやるわけにはいかないので、作業を自動化した。

Pythonスクリプトはこんな感じ：

ラプラス変換とフーリエ変換だけでやってみる試みです。デタラメです。

１次元の波動方程式は次の通り：

$$\frac{\partial^2}{\partial^2 x} u(x, t) = \frac{1}{c^2} \frac{\partial^2}{\partial^2 t} u(x, t)$$

初期条件は $u(x, 0) = g(x)$, $u’(x, 0) = h(x)$ とする。

$t$については因果的なので、$t$ についてラプラス変換すると:

$$\begin{aligned}\frac{\partial^2}{\partial^2 x} U(x, s) &= \frac{1}{c^2} \left( s^2 U(x, s) - s u(x, 0) - u’(x, 0)\right) \\ &= \frac{1}{c^2} \left( s^2 U(x, s) - s g(x) - h(x)\right) \\ \end{aligned}$$

さらに $x$ についてフーリエ変換すると:

$$\begin{aligned}(-j\omega)^2 U(\omega, s) &= \frac{1}{c^2} \left( s^2 U(\omega, s) - s G(\omega) - H(\omega)\right)\end{aligned}$$

これを整理すると：

$$\begin{aligned}U(\omega, s) &= \frac{1}{2c} \cdot \frac{2 (s / c)}{\omega^2 + (s / c)^2} G(\omega) + \frac{1}{2cs} \cdot \frac{2 (s / c)}{\omega^2 + (s / c)^2} H(\omega)\end{aligned}$$

これを逆フーリエ変換すると（$\circledast$は畳み込みを表すこととする）：

$$U(x, s) = \left[ \frac{1}{2c} e^{-(s/c)|x|} \circledast_x g(x) \right] + \left[ \frac{1}{2cs} e^{-(s/c)|x|} \circledast_x h(x) \right] $$

さらに逆ラプラス変換すると：

$$\begin{aligned} u(x, t) &= \frac{1}{2c} \delta(t - \frac{|x|}{c}) \circledast_x g(x) + \frac{1}{2c}\int^{t}_{0} \left( \delta(\tau - \frac{|x|}{c}) \circledast_x h(x) \right) d\tau \\ &= \frac{1}{2} \delta(ct - |x|) \circledast_x g(x) + \frac{1}{2} \int^{t}_{0} h(x - c\tau) + h(x + c\tau) d\tau \\ &= \frac{1}{2} \left( g(x - ct) + g(x + ct) \right) + \frac{1}{2c}\int^{x+ct}_{x-ct}h(\xi) d\xi \\ \end{aligned}$$

Wikipediaに載ってるダランベールの式と同じ解が得られた。

合ってるのかな？

とある入門書に原理を示す図（簡略化されすぎていて実際には動かない回路図）が載っていて、それを見たら実際に動作する回路の姿が気になったので、Analog Devicesの教育用ページを参考に実装した。今回はバイポーラトランジスタ (BJT) を使ったけど、FETのほうが簡単なのかもしれない。

（ちゃんと動作したが、この回路が発振を継続する仕組みについては、いまいち理解できない。）

回路図とシミュレーション結果はこんな感じ。自分が理解しやすいように、先のページに載っていた回路図を変形してある。パラメータを色々いじって低周波（10kHzくらい）で発振させている。

ブレッドボード上に実装：

測定：

理論上の発振周波数は11,254Hz。実測値は11,000Hz。

メモ

• トランジスタのB, C, Eの周りをコイルとコンデンサ（LC回路）が取り囲んでいる。
• インダクタンスの高いコイルを使うとコイルの直列抵抗が無視できなくなる。

仕組み？

出力電圧と、C1からLC回路に流れ込む電流の関係は下図のようになっている。

この電流の変化がコイルの逆起電力を高める。

ここ数年でPython用ライブラリが少し整理されたようで、ちまたの記事は現在の状況に合っていないものが多い。最新っぽいやり方を整理しておく。

最後にGoogle PhotosのAPI (Photos Library API) を呼んでみたので、それについても末尾に書いておく。

oauth2clientはDeprecated

Web上ではoauth2clientを使っている記事がたくさん見つかるが、これは既にdeprecatedになっている。現在は以下のようになっている。

• Service Accountの認証や、Googleのトークンの扱いは、google-authで実装されている。
• OAuth 2.0のフローを行う必要があるときはサードパーティ製のoauthlibなどを使う（google-auth-oauthlibというヘルパも用意されている）。

ライブラリの構成

GCP用も含めて、ほとんどのライブラリはここにある：

• https://github.com/googleapis

以下は（ほぼ）関係ない：

• https://github.com/GoogleCloudPlatform
• https://github.com/google

Google Cloud Platform (GCP) 関係

GCPの各サービスごとにパッケージgoogle-cloud-*が用意されている (例えば google-cloud-storageなど) 。ちなみに、かつて存在したgoogle-cloudというメタパッケージは、既にdeprecatedで空っぽになっている。

これらは以下のような綺麗な名前空間に収まっている。

import google.cloud.speech

• repo: https://github.com/googleapis/google-cloud-python
• doc: 各google-cloud-*ごとに個別に存在する。上のURLからたどれる。

各サービスで共通の部分はgoogle-api-core, google-cloud-core, google-resumable-mediaなどのパッケージとして抽出されている。これらは必要に応じて依存パッケージとしてインストールされるのであまり気にしなくていい。

Google’s Discovery-based API

google-api-python-client - これはGoogleのサービス（Google Driveなど）のAPIを叩くための汎用ライブラリ。API定義をネットから取ってきて、APIを表現するオブジェクトを手元で動的に組みたてる仕組みになっている。

import googleapiclient

• repo: https://github.com/googleapis/google-api-python-client
• docs: https://github.com/googleapis/google-api-python-client/blob/master/docs/README.md
• docs: http://googleapis.github.io/google-api-python-client/docs/epy/index.html

ただしGCPを扱うときはこれを使うべきではない。「GCPについてはアクティブに開発されているGCP用のライブラリを使え」とのこと。

google-auth

認証周りを抜き出したもの。Service Accountの認証のほか、トークンのverifyなどもこれでできる。google-cloud-*とgoogle-api-python-clientはこれに依存している。

google-auth:

• repo: https://github.com/googleapis/google-auth-library-python
• docs: https://google-auth.readthedocs.io/en/latest/

google-authには、ユーザクレデンシャルを取得する（=OAuth 2.0のフローを助ける）機能がない（oauth2clientにはあった）。アクセストークンを取得したければ、oauthlibなどをそのまま使うか、Googleが用意しているヘルパーgoogle-auth-oauthlibを使う。

（もちろん、Webフロントエンドなどがある場合はブラウザ上でGoogle Sign-Inなどを使ってアクセストークンを取得すればいいので、サーバ側はトークンの検証だけすればいい。）

google-auth-oauthlib:

• repo: https://github.com/googleapis/google-auth-library-python-oauthlib
• docs: https://google-auth.readthedocs.io/en/latest/

認証方法

これはPython特有ではないけど…

Google Cloud Platformの認証の種類は以下の通り：

• Service Account - server-to-serverの通信には基本的にこれを使う。OAuth 2.0に基づいている（がOAuth 2.0そのものではない？）。
• OAuth 2 - ふつうのOAuth 2.0のフロー。ユーザの同意を得て、ユーザのデータにアクセスするためのトークンを取得するときに使う。
• API Key - APIキーによる認証。一部のAPIを使うときに必要。

Service Account

推奨される方法： クレデンシャルファイルを利用する。環境変数 GOOGLE_APPLICATION_CREDENTIALS でクレデンシャルのjsonファイルのパスを指定しておけば、あとはライブラリが裏で勝手に認証を行ってくれる。

上記の通り、通常はライブラリに任せればいいのだけど、内部的には次のようなことをしている → クライアントの秘密鍵で要求用のJWTを署名して、それをエンドポイントに送信してアクセストークンを取得し、そのトークンでAPIを呼ぶ。（Pythonだと、google/auth/service_accounts.pyのrefresh()あたりを追うとわかる）。

JWTの署名アルゴリズムにはRS256（256bit RSA暗号）が使われる。一部のAPIでは、上記のJWTそのものをそのままアクセストークンとして使うこともできる。

OAuth 2.0

Googleが提供しているGoogle Sign-In (Web (JS), Android, iOS, TV, etc.) などの認証ライブラリが使える場合はそれを使えばアクセストークンを取得できる。認証時に必要なスコープを要求すればいい。

上記で対応できない場合は、PlainなOAuth 2.0を使う（デスクトップアプリ、CLIツールなど）。

Pythonの場合は、PlainなOAuth 2.0フローを簡便に行うためのgoogle-auth-oauthlibパッケージも用意されている。

実際にやってみる。

google-cloud-*のほうは分かりにくいことは特にないので触れない。ここではgoogle-api-python-clientを使ってみる。

コマンドラインから自分のアカウントのGoogle Photosの写真を列挙してみることにした。

事前準備として、Google Cloud Consoleで適当なOAuth 2のクライアントIDを作っておく必要がある。

そして、コード自体は以下だけでOK。短い。

from google_auth_oauthlib.flow import InstalledAppFlow
from googleapiclient.discovery import build

# Obtain an access token
flow = InstalledAppFlow.from_client_secrets_file(
    'client_id.json',
    scopes=['https://www.googleapis.com/auth/photoslibrary.readonly'])
credentials = flow.run_local_server()

# Call the Photos Library API
photos_service = build('photoslibrary', 'v1', credentials=credentials)
result = photos_service.mediaItems().list().execute()
print(result['mediaItems'])

実行するとブラウザが開いてGoogleの認証ページが表示される。デスクトップアプリやCLIのツールでアクセストークンを受け取るためのトリックとして、ローカルにWebサーバを立ててそこをOAuthフローのリダイレクト先にする、ということを行うのだが、その一連の処理はgoogle_auth_oauthlibのInstalledAppFlowがすべてやってくれる。

まずLTSpiceでシミュレーションした。2次バターワースフィルタのつもり。

これでいいのかどうかわからないけど、それっぽい曲線にはなっている。

これをブレッドボード上に実装：

これをAnalog Discovery 2で見たら、ほぼシミュレーション通りの結果になった。

そういえば、初めに測定したときに周波数特性のプロットがひどくガタガタになるなあと思ったら、ジャンパワイヤが錆びていたようで、紙やすりでこすっただけで解決した。

ちなみに矩形波を入力したときの出力はこんな感じ。

さいきん興味があるのは主にこんなところ。

• アナログ電子回路らへん
  • ハードウェアへの憧憬
• 無線工学（？）
  • いままで全く興味なかったけどなんだか楽しそう。自分のほかの興味分野と関連してそうな感じがする。
  • しかし本質的に理解したいなら電子工学や電磁気学やベクトル解析のセンスが要求される感じ。その辺も楽しいのかもしれないけど、そこまで足をつっこむべきかどうか。
• 色彩工学
  • デザイナー向けではなく、エンジニアリング寄りのやつ。重要そうな分野なのに教科書が少なくて謎深い。洋書も少ない。なんでだろ。

いきなり学生向けの教科書を読まずに、まずはライトな入門書をながめようとしている。

どの分野も事前知識がないので学習曲線がsteep。しばらく本を読んで雰囲気をつかむ感じか。

（ちなみに私はマイコンの知識はほとんどないし、MbedもPlatformIOも今回はじめて触るので、暗中模索でやっている。）

このボードの特徴は、Mbed対応のボードとしては安い（1個850円）ことと、シリアル経由ではなくMbed的に単体でUSB経由で書き込めること（USBマスストレージとして認識されるので、そこにfirmware.binを突っこむだけで書き換えられる）。

ハマった点

Mbed公式のオンラインコンパイラでビルドしたBlinker（Lチカ）をFinderでいくら書き込んでも全く動作しなくて10分くらい悩んでいて、ふと思いついてコマンドラインからcpやddを使って書き込んだらうまくいった（Linuxでも同様？）。

しかし、PlatformIOで同じLチカコードをビルドしても全然動かない。PlatformIOがMbed OS 5.x系を使うからなのかなと思ったが（このボードはMbed OS 2まで対応と書いてあるので、解決は面倒くさそう…）、そういう話ではなかった。

どうやらマイコン側でファームウェアのチェックサムを調べるらしくて、PlatformIOでビルドしたあとにファームウェアのチェックサムを適切に書き換えてやる必要があるようだ。シリアル (SWD?) で書き込むときは書き込みツールがこの辺の面倒をみてくれるんだと思うけど、mbed的に書き込むときはチェックサムの書き換えが必要になる。

準備

LPC用ファームウェアのチェックサムを書き換えるPythonスクリプトを入れておく。

pip3 install lpc_checksum -U

PlatformIOでの開発

PlatformIOを初めて使うので、安直にVSCodeのPlatformIO IDEを使った。

まずふつうに適当なプロジェクトを作る。ボードは EA LPC11U35 QuickStart Board を選択し、フレームワークはmbedを選択する。

アップロードスクリプトを作る

~/.platformio/nxplpc_osx_usbisp.sh（名前はてきとう）に以下のようなシェルスクリプトを置いておく。ファイルのパーミッションを755にするのを忘れずに。

#!/bin/sh

SOURCE=$1

lpc_checksum $SOURCE
rm -f /Volumes/CRP\ DISABLD/firmware.bin
dd if=$SOURCE of=/Volumes/CRP\ DISABLD/firmware.bin

これは一度作っておけば他のプロジェクトでも使い回せる。

platformio.ini

プロジェクト直下の platformio.ini を開き、アップロード時に上記のアップロードスクリプトが実行されるように設定する。

[env:lpc11u35]
platform = nxplpc
board = lpc11u35
framework = mbed
upload_protocol = custom
upload_command = $PROJECT_PACKAGES_DIR/nxplpc_osx_usbisp.sh $SOURCE

これで終わり。

ボードを書き込みモードにして、PlatformIOのUploadを実行すれば書き込まれる。無事にLチカが動いた。

問題

結局のところ、Mbed OS 5.x系のライブラリを使ってRTOSなしでビルドしているようだ。USBHIDなどのライブラリを使おうとするとビルドが通らなくなる。…だめじゃん。

それと、自分の設定が悪いのかもしれないけど、PlatformIOでmbedプロジェクトをビルドすると、毎回すべてのファイルをコンパイルするのでめちゃくちゃ時間がかかる。

その後、PlatformIOじゃなくてmbed-cliも少しだけ試したけど、Mbed 2.x 対応 (--mbedlibオプション) 周りのライブラリダウンロードの仕組みが壊れてるっぽい… 手動でライブラリをダウンロードしてやっと動いた。

つらい。

学生のときはまったく理解できていなかったなとしみじみ思いつつ、読み直して思い出したこと、分かったことを列挙しておく（…どうせまた全部忘れるので）。

(こういうのを理解して使いこなしている人達ってすごいな…)

DTFT

• 時間ドメインと周波数ドメインの一方を離散化すると相手は周期化する。
  • つまりDTFT では周波数ドメインが周期化する
  • 連続信号のスペクトルとそのサンプリング信号のスペクトルの関係はよく知られている通り。
  • この関係により、周波数ドメインがナイキスト周波数に収まっているとき（つまり有限のとき）、時間ドメインを離散化しても元のスペクトルの情報は失われない。これがサンプリング定理。

DFT

• DTFTから更に周波数ドメインも離散化すると、時間ドメイン（離散的）も周期化する。
• DFTは、計算上は有限個の離散値を扱うが、実際には時間ドメインも周波数ドメインも離散的かつ「周期的」であることを忘れてはいけない。
• （サンプリング定理と同じように…）時間ドメインが有限長のとき、周波数ドメインを離散化しても時間ドメインの情報は失われない（つまりDTFTをDFTで実行できる）。

エネルギー

• 「時間軸での二乗和（エネルギー）」と「パワースペクトルの積分」は定数倍の関係にある（パーセバルの関係式）。このことは、どの周波数にエネルギーが集中しているのか知ることができるということを意味する。この関係は、FTでもDTFTでもDFTでも成り立つ。

線形時不変システム (LTIシステム)

• LTIシステムの出力は、入力信号とインパルス応答の畳み込みで記述できる。これは連続システムでも離散システムでも同じ。
• 時間ドメインでの畳み込みは、フーリエ変換やDTFTのドメインにおける積である。つまりLTIシステムというのは、入力信号のスペクトルに、周波数特性（＝インパルス応答のスペクトル）をかける操作を行う。

伝達関数

• ラプラス変換では、扱う信号がすべて因果的であるときに畳み込みの性質が成り立つ。つまり Y(s) = H(s)U(s) となり定数項はゼロとなる。つまり入力と出力の比 H(s)=Y(s)/U(s) が計算できる。H(s)を伝達関数と呼ぶ。（ちなみに過渡解析などでは、定数項が生じ、それが初期条件となる）
• ラプラス変換では虚数軸上の点が周波数特性を表し、z変換では単位円周上の点が周波数特性を表す。
• ラプラス変換では線形微分方程式システムの伝達関数が有理多項式であり、z変換では差分方程式システムの伝達関数が有理多項式である。
• ラプラス変換の有理多項式ではすべての極が負の側にあるときに安定、z変換の有理多項式ではすべての極が単位円周内にあるときに安定。

フィルタ

理想フィルタは因果的線形システムでは作れない。これをいかに近似するかを、フィルタの近似問題という。

FIR

直線位相かつ常に安定。しかし急峻さを得るには高い次数が必要。

• 窓関数法
  • 理想フィルタを逆DTFTして得られる無限長インパルス応答を、適切な窓関数でぶった切って（周波数ドメインにスムージングがかかる）、時間方向に推移させる（周波数ドメインに直線位相が加算される）ことで、因果性信号にする。

IIR

低い次数で急峻な特性が得られる。しかし直線位相は近似的にしか目指せず、安定性も設計で考慮する必要がある。FIRより設計が難しい。

アナログフィルタを変換して作る方法は：

• インパルス不変法
  • アナログフィルタの有理多項式による伝達関数を部分分数分解すると、各項の逆ラプラス変換は減衰する指数関数でなる。これをサンプリング (つまりtをnTで置換) したものをz変換する。
  • この仕組み上、元のインパルス応答の周波数特性がナイキスト周波数に収まっている必要がある。つまりローパスフィルタとバンドパスフィルタにしか適用できない。
• 双一次変換法
  • sとzとのあいだに双一次有理多項式による変換関係を定義して、ラプラス変換の有理多項式をz変換の有理多項式に変換する。

写真の中央が本体で、その左右のBNCプローブアダプタとかインピーダンスアナライザとかは別途に新品を買った。

いわゆる「USBオシロスコープ」、つまりパソコンに繋いで使うオシロだ。シグナルジェネレータやデジタルI/Oの機能も付いていて、それらとオシロ機能が連携することで、周波数特性などの測定も手軽にできるらしい。

自分のような電子回路のど素人でもオシロスコープは持ってるに越したことはないらしい。本当は5万円くらいの中国メーカーのオシロ（据置型）を買おうかどうか悩んでいたんだけど、一旦保留することにした。

機能

仕様を書き写してみる：

• オシロスコープ (2ch, ±25V, 14bit, 100MSa/s, 30MHz+)
• 任意波形生成器 (2ch, ±5V, 14bit, 100MSa/s, 12MHz+)
• DC/AC電圧計 ±25V
• プログラマブル電源 (2ch, 0〜+5V, 0〜-5V, ただし出力は弱い)
• スペクトラムアナライザ (0Hz〜50MHz)
• ネットワークアナライザ (1mHz〜25MHz)
• インピーダンスアナライザ (100μHz〜25MHz)
• 16ch ロジックアナライザ (100MSa/s)
• 16ch ディジタルパターンジェネレータ (100MSa/s)
• 16ch プロトコルアナライザ (SPI, I2C, UART, CAN)
• 16ch ディジタルI/O（ボタン、スイッチ、LED、etc.）
• 双方向外部トリガ 2ch

それぞれの機能の性能は専門の機材に及ばない（用途によっては使い物にならない）のだけど、学習者やホビーユーザならこれで十分な状況も多いと思う。というか学習者向けを志向して作られているようだ。ソフトウェアも良くできてそう。要するに、自分のような入門者の勉強用にはちょうどいいと思う。

詳しいことはリファレンスをみればわかる。

https://reference.digilentinc.com/reference/software/waveforms/waveforms-3/reference-manual

https://reference.digilentinc.com/reference/instrumentation/analog-discovery-2/reference-manual

（ちなみに今5万円前後で買える中国製オシロ（単体型）は、サンプリングレート1GSa/sで、周波数帯域は100〜200MHzというのが主流だとおもう）

LEDライトのチラツキを測定してみる

なにかオシロじゃないと測定できない身近なネタはないか考えていたら、手元にフォトダイオードが１つあったので、これでLEDライトのチラツキを測定できるんじゃないかと思いついた。

LED照明（天井ライト、デスクライト、etc.）の内部回路というのはピンキリで、商用電源を一切平滑化せずに100/120Hzで明滅するようなものから、ちゃんとインバータが備わっているものまで色々ある。100Hzで明滅するようなものはなんとなく視神経に悪影響がありそうだし（どうなんだろ）、その照明下で動画撮影をするとひどいフリッカーが起きたりもする。

実際に測定してみる。上の写真のようにフォトダイオードと抵抗 (22kΩ) を直列につないで、Analog Discoveryの電源機能で5Vを供給する。光の強さに応じてフォトダイオードに流れる電流が変化するので、抵抗の電位差をオシロ機能で測ればいい。

パナソニックのLEDシーリングライト

まずは部屋のLEDシーリングライト（Panasonic製）の光を測定してみる。結果はこんな感じ（実際にはリアルタイムに波形が見れる）。

人間にはチラツキなど感じられないが、実際の明るさは波打っていて、その周波数は301Hz、つまり商用電源の6倍の周波数。さすがに点灯と消灯を繰り返していることはなくて、それなりに直流成分があるが、明るさの変化（波形の上下）がそこそこあるように思う。

このシーリングライトは低〜中価格帯の製品なので、高価格帯のものはもっとよくできているのかもしれない。

そういえば周波数とかRMSとかの統計値を簡単に表示させられて便利だ。こういう機能の呼び出しは、単体のオシロよりもこういうPCオシロのほうが操作しやすそう。

LEDデスクライト (Taotronics Eye-Protection LED Desk Lamp)

Amazonで売れてるやつ。タイムセールで3000円で買った。

https://www.amazon.co.jp/dp/B00VV6BM9K/

波形はこんな感じ。まったく違う。

さっきのPanasonicのシーリングライトと公平に比較するため、DC RMS = 200mVに合わせてある。

シーリングライトに比べると波形の振幅は５分の１くらい。周波数は52000Hzで、シーリングライトの170倍以上。これがまさにインバーターって感じなのだろうか。さすがにこの周波数だと人間には知覚しようがないし、そもそも振幅が小さい。

目に優しいといいながら実態はどうなのかと思っていたが、少なくとも平滑化に関してはちゃんとしていてすごいと思った。（Amazonレビューで不正するのをやめればいいのに）。

ということで、オシロスコープを初めて使った体験でした。電子回路ではなく明るさの測定に使ってしまった。

この手のシャッター操作の自動化はリモートコード経由で行うのが安定的で良いだろうけど、単なる遊びのために手元のリモートコードを切りたくはない。

NikonやCanonの一眼レフは、リモートコードのほかに赤外線リモコンでもシャッターが切れるようになっているので、今回はその機能を利用することにした。ちなみにリモートコードは半押しやバルブに対応しているけど、赤外線リモコンではそれはできない。

発光パターン

赤外線リモコンの仕組みはTVだろうとエアコンだろうと同じで、リモコン側はメーカー固有のパターンで赤外光をON/OFFさせて、受信側はその固有パターンを検出して反応する。

自分はNikon用の赤外線リモコンを持っていないので発光パターンを調べることができない。仕方がないので今回はすでに同じことをしている人の知恵を借りることにする。（ついでにいうと、自分はまだオシロスコープすら持ってないし、赤外線を受信できる素子も持ってないのでどっちにしろ計測は無理。）

Nikon D40用天体撮影インターバルタイマー作成

この方の調査によると、Nikonのリモコンの発光パターンは以下のようになっているそうだ。横軸が時間。

変調

じゃあこのタイミング通りにLEDをON/OFFすれば解決かというと、話はそこまで単純ではない。赤外線リモコンの発光は変調されている。

というのも、仮に世の中の赤外線リモコンが上のような単純なパターンを送受信していたとすると、他の光源の影響をモロに受けて誤作動する可能性が極めて高いからだ。

そこで大抵のリモコンは信号を38kHzに変調して送信している。そして受信側の赤外線受信モジュールには38kHzの周辺のみを取り出すアナログフィルタがついていて、それによって他の雑多な光源の影響をリジェクトするようになっている。

変調といっても実際にやることは簡単で、38kHzの矩形波をキャリアにすればいい…….要するに下図のように波打たせる。

このようなパターンでLEDを発光させれば、カメラが反応するはずだ。

実装（簡単）

簡単に済ませたいのでArduinoでコードを書く。マイコンは、何かのおまけでもらった “Adafruit Pro Trinker” というArduino互換マイコンを使った。

ひとまずこんな感じで赤外線LEDをつないでD9ピンの電流で駆動させる。ちなみにピンによっては38kHzの速さでスイッチできないものもあるみたい。

Arduinoのコードは以下のようにフラットに書いた。 変なビット操作をしているけど、これはArduinoの digitalWrite(...) を使うと動作が遅くて発光タイミングに影響するかもしれないのでレジスタの直接操作でピンの出力を切り替えているというだけ。

void setup() {
    pinMode(8, OUTPUT);
}

void loop() {
    _delay_ms(100);

    for (int i = 0; i < 77; i++) {
        PORTB |= B00000001;
        _delay_us(13);
        PORTB &= ~B00000001;
        _delay_us(13);
    }
    _delay_us(28429);

    for (int i = 0; i < 17; i++) {
        PORTB |= B00000001;
        _delay_us(13);
        PORTB &= ~B00000001;
        _delay_us(13);
    }
    _delay_us(1636);

    for (int i = 0; i < 17; i++) {
        PORTB |= B00000001;
        _delay_us(13);
        PORTB &= ~B00000001;
        _delay_us(13);
    }
    _delay_us(3676);

    for (int i = 0; i < 17; i++) {
        PORTB |= B00000001;
        _delay_us(13);
        PORTB &= ~B00000001;
        _delay_us(13);
    }
}

一眼レフ側で赤外線リモコンの使用を有効にしておく。

Arduinoにコードを書きこんでカメラを近づけたら、あっさりとシャッターが切れた。

おわり。

FETをかます

マイコンの出力ピンで直接LEDを駆動させずに、FET (NMOSFET) でスイッチングするようにしてみた。そうしたほうが十分な電流を流せて赤外線の出力が上がる。マイコンの負荷も少ないだろう。（…というかFETを試しに使ってみたかっただけ）。

今回使った赤外線LEDは、電圧降下が1.7Vで電流は100mAくらい流しても平気のようなので、抵抗は33Ωくらいまで下げてもいい（私は47Ωを使った）。

ストロボでも同じことができそう

Nikonのクリップオンストロボは複数台のストロボを連携させられる機能をもっている。例えば、カメラのシャッターを切るときに内臓ストロボからコマンドを送出して、そのへんに置いてある複数台のクリップオンストロボを同調させて光らせる、とかができる。

この通信も赤外光なので、頑張れば自前で制御可能かもしれない。

Original Prusa i3

価格と性能のバランスがいいという評判で、Makeとかでもおすすめされている。YouTubeで海外の3Dプリンタ系のチャンネルをみるとよく出てくる。世界的には良く売れている機種で、既に10万台以上売ったようだが日本での知名度は高くない。最新版はMK3Sというモデルだ。

“Prusa”という名称は開発者の Josef Prusa から。てっきりアメリカ人か何かだと思っていたら、チェコ人のお兄さんだった。髭面のオヤジに見えるが、1990年生まれで、まだ20代。

オーンソースハードウェアなので、これを派生させたプリンタがいろいろと存在する。Amazon.co.jpで上位にいる中国メーカーのものは実はそれが多かったりする。

面白いと思ったのは、このプリンタのパーツも3Dプリントで製造されている点だ。

自分で組み立てるKit版と、組み立て済み版がある。組み立て済み版は値段が1.5倍くらいする。

購入は、チェコ本国のサイトとAmazon.co.jpでできるが、送料と消費税を考えると両者の価格に大きな差はない。自分はAmazonでKit版を買った。

ダンボールを開けたらHARIBOが入っていて笑った。組み立てマニュアルの各章のおわりに「ここでHARIBOを5個食べましょう」とか書いてある。

Amazon.co.jpで買うと日本語マニュアルが付いてくるけど、公式サイトには最新の英語版マニュアルがあるので、英語がすごく苦手でなければ特に要らないかも。

組み立てる

自分は組み立てに8時間掛かった。作業に専門的なスキルは要らなかったしマニュアルも十分にわかりやすかったし専門的な工具も要らない。でも、組み立ては楽とは言えないし精神的にもけっこう疲れた。とはいえ一度組み立てると構造が分かるので、その後のメンテナンスのことを考えると一度は自分で組み立てたほうがいいと思う。

外箱を開封すると小箱が出てくる。

小箱を開封すると、パーツが現れる。

まずは骨格を組み立てて、そこにY軸（奥行方向の軸）を作る。骨格はさすがに剛性と精度が必要なので、3Dプリントではなく、金属を切削加工したものと、アルミの押し出しで作られている。

このへんの組み立ては簡単。

次は、Z軸（高さ方向の軸）とX軸（横方向の軸）を組み立る。（写真撮り忘れた）

その次にエクストルーダーを組み立てる。これはインクジェットプリンタでいう「ヘッド」に相当する部分。マニュアルにも書いてある通り、これの組み立てが最難関。このエクストルーダも、電子的なパーツ以外はすべて3Dプリント部品でできている。（このへんも写真撮り忘れた）

組み上げたエクストルーダを、X軸に取り付ける。

ここまでやって、こんな感じ。

さらに、操作パネルを取り付けたり、電源ユニット (PSU) を取り付けたり、ヒートベッドを取り付けたりする。このへんは楽勝。

最後に、マザーボードを取り付けて配線する。ボックスが狭くてやりにくい。ケーブルの処理はけっこう厄介。

これでおわり。完成。

キャリブレーション

初回起動時はセルフテストが行われる。電気的な部品（ステッピングモータ、ファン、ヒーター、センサー、etc.）の動作をそれぞれチェックしてくれる。こういうチェックがあるのは良い。

その次はキャリブレーションを行う。エクストルーダにPINDAセンサーというのがついていて、そのセンサーで印刷台（ヒートベッド）の上をあちこちスキャンして、X, Y, Z軸のゆがみや、印刷台 (heatbed) のゆがみを測定する。この結果を、印刷時のソフトウェア補正に利用するらしい。

キャリブレーションはほぼ全自動で進む。

巷の評価によると、このキャリブレーションがよくできているのがPrusa i3の強みだそうだ。つまり、筐体だけでは出せない精度を、優秀なセンサーと優秀なソフトウェアで実現するということらしい。

キャリブレーションの途中で、ヒートベッドの上にスチールシートを取り付ける。（ちなみに実際に印刷するときは、このスチールシート上で印刷する。）

スチールシートの上で、さらにキャリブレーションを進めていく。

キャリブレーションが終わると「X軸とY軸は垂直です。おめでとう」という英語の表示が出た。どうやら最良の結果らしくて安心した（しかも詳細情報によるとskew 0.00°）。ちなみにネットの情報によると、「わずかに歪んでいるが問題ないよ。グッジョブ」という表示が出ることもあるらしい（特に旧バージョンのMK2で）。仮にそういう結果になっても、ソフトウェアが優秀なので出力品質にほぼ影響しないらしい。

テスト印刷

印刷は、SDカードにデータを入れて行うか、PCと接続して行う。SDカードから印刷するならPCを接続する必要はない。

印刷用データは、CNC工作機械の制御で標準的に使われている “gcode” という形式を使う（このデータを自分で作るときは、3DCADや3DCGソフトで作った3Dモデルを、「スライサー」と呼ばれるソフトウェアで処理する）。

付属のSDカードに入っていた「Treefrog 50μm」（アマガエルみたいなモデル）を印刷してみることにした。50μm (=0.05mm) というのは積層レイヤ1枚の厚みを表している。50μmは熱溶解積層法のプリンタにとってはけっこう精密なデータらしい。他のサンプルデータは150μmや200μmが多い。

液晶画面の指示の通りにフィラメントをエクストルーダに挿入する。フィラメントを挿入すると、フィラメントセンサーが働いて、自動で巻き込みが始まる。

印刷するTreefrogのサイズはけっこう小さいが、精密なデータなので印刷に4時間弱かかるという表示が出た。

印刷をスタートさせて、すごく疲れていたので昼寝した。で、目が覚めたら何のエラーもなく出来上がっていたので拍子抜け。

スチールシートをプラットフォームから取り外して、シートをグニャリと曲げると印刷物（カエル）がシートから剥がれる。

背中はつるつる。

蜘蛛の糸のようなものが生じていて汚いが、複雑なモデルにおいてこれが発生するのはある程度仕方がないようだ（Stringingという）。人間の手で研磨などの処理をしてやれば綺麗に仕上がる。

わかったこと

• 熱溶解積層法の3Dプリンタはあくまでホビー用…と思いきや、このプリンタの部品が3Dプリントで作られているように、実用可能な製品のパーツを作ることもできる。
• 動作音は想像していたよりも静かだった。置く場所や方法を工夫すれば深夜のアパートでも余裕で動作させられると思う。より静音にするためのステルスモードもあるらしいが、まだ試していない。
• 組み立て作業に高い精度は求められない。常識的な丁寧さで作ればちゃんと動く。
• ハードウェア自体はけっこう単純なので、それを支援するソフトウェアが重要な役割を果たす。
• 機械系の人たちには常識なんだろうけど、ステッピングモータとベルトだけでこういう精度が出せるのはすごい。
• PCをつなぎっぱなしにする必要はない。SDカードで印刷できる。良い。
• フィラメントを押し出す部分をエクストルーダ (extrude = 押し出す) と呼ぶ。ステッピングモータは、XYZの各軸に加えて、エクストルーダにも付いている (E軸)。これによって、フィラメントをヒータ内に取り込む量、つまり射出量が制御される。
• エクストルーダにはフィラメントを溶かすためのヒーターが付いていて、稼働時は200〜250℃になる。物体を出力するプラットフォームにも造形物が外れないようにするためのヒーターがついていて、こちらは60〜80℃くらいになる。これらの温度はフィラメントの材質 (PLA, ABS, PETG, etc.) に応じて適切に変える。

今後

自分はこういうカエルを印刷したいわけではない。

いずれにしても、3DCAD/CAM/CAEを覚えて損はないだろう。Fusion 360を少しだけ触ってみたが、目的の形状を作る作業はパズルを解くみたいで楽しい。単に図面を引くだけでなく、画面上で構造物を組み立てて稼働させたりできるのもすごい。まだぜんぜん分かってない。

リニアベアリングの品質

組み立て時に、リニアベアリングが金属ロッド上で結構ひっかかる感じがした。実際に動作させるまでずっとこれが気がかりで、気になってしまって組み立て作業が止まったりした。

結果的には出力品質に問題はなさそうなので、ベアリングの品質が多少悪くても深刻な影響はないのかもしれない。ただし静音性に影響している感じはしなくもない。印刷時には各軸が高速に移動することがたまにあるが、そのときはけっこうギャーギャー鳴く。

フォーラムの情報を見ると、日本のMISUMI製などの上質なベアリングとロッドに交換する人もいるようだ。