草コイン「おがコイン」を発行したら5000兆円ぐらい獲得した(気分になった)

タイトルは釣りです。

これは「5000兆円持っている」と言っても過言ではないのでは・・・？ pic.twitter.com/WpZveC0bin

— やみつきー(小笠腹)＠75.5kg (@YAMITZKY) 2018年2月12日

こちらのツイートを見てもらえると分かるとおり、僕の資産が約38兆ドル(4,180兆円)相当になった気分になりました。5000兆おがコインという暗号通貨(トークン)を4180兆円で買いたい人がいないので、実質的には5000兆円獲得してません。

経緯

先日、気がついたら社内に「おがコイン」とかいう絵文字ができてました。ティッカーシンボルは「OGA」っぽい。えっ

なので、本当に「おがコイン」作ってみるかーと思って、WAVES のブロックチェーン上に 5000兆おがコインを発行してみたという経緯です。

ちなみに何故「ドル」表記がツイートの画像に付いていたかというと、実際に WAVES の DEX (取引所) 上で売り買いを行ったからです。1おがコインを適当な値段で自分で売って、自分で買ったら、こういう値段になりました。

ただし、同じ値段で全おがコインを売ることはできないと思うので、本当は 4180 兆円の価値はありません。暗号通貨の所持自体に税金が掛からなくてよかったです。これで海外に住居移したらまずいんでしたっけ。

おがコインのメリット

特にないですが、買ってくれたら小笠原が喜びます。

だいたい 1 おがコイン＝1 円ぐらいで WAVES の取引所上で売り出しているので(BTC/ETH/ZCH)、2000 おがコインぐらい買ってくれたら僕の時間を 1 時間ぐらい拘束できるかもしれないですが保障はしません。※ プレセール期間中(？)なので、実際の人件費とは比例しません。

あとは弊社関係の人は飲み会の精算にもどうぞｗ

アセットID は J2wfXzV6NEzq1kgiVx3tFbXvBA2yxz1jtGKaBvXjhn5m です。類似したスキャムコインに注意して下さい。

オリジナルトークンについて

暗号通貨(仮想通貨)は一般に、ブロックチェーン上に、正しくトランザクション(残高のやりくり)を記録していきます。逆に言うと、インセンティブさえあれば、ブロックチェーンに記録するのは暗号通貨そのものである必要はなく、「資産」一般に使うことができます。今回発行した「おがコイン」もその一つで、しばしば「トークン」と呼ばれます。誰かが支払いとして受け付ければ、それはやはり「通貨」だと思うので「通貨」「コイン」という表現をしましたが、「株」とか「ポイント」とかの方が概念的には近いでしょうか。

Waves Platform はそういう「独自トークンの発行」という機能を持ったブロックチェーンです。手数料は 1 WAVES です(7ドルぐらい)。普通は ICO とかに使うと思います。類似したものに、Counterpartyとかカラードコインとかがあります。

オリジナルな VALU に近いですね。おがコインを販売していって、それを「株主優待」として還元したりすることもできるでしょう。

草コインの交換に発生する税金について

僕は約4,180兆円相当のおがコインを持っていますが、5000兆「おがコイン２」を作って、「おがコイン」を「おがコイン２」に全額変換したら、4,180兆円相当の課税が発生するのでしょうか。2000兆円ぐらいは税金に持って行かれるでしょうから、日本の借金が軽く吹っ飛ぶ算段です。日本の未来は明るい。

草コインの拾得に発生する税金について

僕の約4,180兆円相当のおがコインを誰かに送りつけたら、誰かは2000兆円ぐらいの税金を払う必要があるのでしょうか。日本の未来は明るい。

DEX について

WAVES の取引所は DEX と呼ばれます。

DEX というのは、分散型暗号通貨取引所です。ようするに、coincheck みたいな取引所をブロックチェーン上で記録しながら行っているものだと思いますが仕組みは知らないので間違ってたらごめんなさい。

DEX は、いわゆる「草コイン」が取引できることが多いです。WAVES の場合、誰でも「草コイン＝トークン」を作って上場することができます。WAVES には ETH とか BTC とか Zcash とかもあります(これらはもちろん草コインではなく、公式のものです)。

DEX を使いたい人は通常、BTC を coincheck みたいなところで購入して、DEX に預け、DEX 上で取引を行います。DEX の登録にはメールアドレスは不要で、アドレスさえ作ればいいので匿名でできます。(バグがないかぎりは)取引所から盗んだり倒産したりということもないでしょう。

DEX がある以上、金融庁が匿名暗号通貨を規制したところで、あんまり意味ないんじゃないでしょうか。coincheck が流出させた XEM も、数年間寝かされた後、ダークウェブなしに換金されるでしょうし、NEM財団や警視庁、金融庁がどうしたいのかはわからないです。

独自トークンの意味

余談ですが、自分は暗号通貨の活用に関して、「なぜこれが既存の中央集権型システムより優れているのか」を考えるようにしています。独自トークンに対する「既存」は、企業が独自に作るポイントなどがこれに該当するでしょう。

WAVES 上に独自トークンを作ると、たとえ小笠原が死んだとしても「おがコイン」という資産はブロックチェーン上に残り続けます。ですが利用価値はゼロに近づいていくでしょう。そのあたりは、倒産した会社の株に近いと思います。死なないまでも、ICO関係の詐欺も同じことです。

独自トークンを作る意味というのは、次の３つに集約されると思います。

1. 支払いに数銭の手数料を上乗せすることで、インフラのタダ乗りができる
2. 他の暗号通貨に換金できる
3. プログラム上で詐欺を防ぐ仕組みがある(WAVESではまだできないが)

2 に関しては、ウェブサービス等上で使える「ポイント」を「トークン」としておけば、ユーザーは人手を入れずポイントを換金できることになります。大黒屋includedなポイントサイトですね。マネロンに使えそうなので、そもそも日本だとトークンの組み込みは合法なのだろうか。。。。

3 は、DAICO とかバンコールが近いのかなと思っています。独自トークンで儲けるためには、詐欺をするディスインセンティブがあり、誠実に契約を履行した方が良い、と。詐欺は、警察が頑張って捕まえようと「入所年数に対して何円儲けられるか」の労働なので、「そもそもプログラム的に引き出せなくなる」というのは重要なんじゃないかという所感です。

とはいえブロックチェーンに載せるデメリットもあるので、普及するのかは知らん。以上。

AWS の CloudWatch Logs を便利に見れる GUI 環境を作ってみた

github.com

github.com

コンセプト

先行アプリケーションとして awslogs という CLI がある。これを GUI ＝ ブラウザで見れるようにしたもの。なので awslogs-gui、awslogs-api という名前だし、パラメータやデフォルトの挙動は awslogs に倣っている(API の依存ライブラリですらある)。

awslogs-api は awslogs の機能を API として提供していて、 Swagger も用意している。

awlogs-gui は awslogs-api を叩くための SPA として作っている。

CloudWatch Logs 公式管理画面の問題点

いくつか問題点があると思っている。

• 管理画面の認証：AWSの管理画面が提供する認証方法しか提供していない。例えばイントラネットであればOK、 ベーシック認証、セッション時間を伸ばすなどができない(のもセキュアで正しくはあるんだけど)
  • へーしゃの場合だと Google 認証に統一しているが、セッション時間が短い。かつ、Switch Role して管理画面にたどり着くのが面倒(けど、これは僕が知らないだけで回避策があるのかもしれない、、、ので教えて欲しい)
• ページング前提の UX
  • キャッシュして、ローカルでインクリメンタルサーチとかした方が便利なのでは
• ログの表示順
  • 時系列にならべて、これもインクリメンタルサーチしたい

その点 awslogs は大変重宝しているけど、全員(例えば非エンジニア)に使いやすいわけではない。もちろんCLIの方が便利なケースもある。

使ったもの

• Vue
• Vuex
• Parcel (非Webpack)
• element-ui
• awslogs
• Swagger (connexion)

いつものように Docker ベースで作成。

Parcel は、詰まらない限り便利なので、今後も簡単なユースケースに使っていきたいし、進化のスピードが速いので、僕がハマってた何かを誰かが解決してくれてるかもしれないし僕も解決していきたい。

Vue / Vuex で作ったもののソースコードを外に出すのは初めてだったりする、、、ギョームでも使ったこともないので、まだまだ汚い。

API の方では、Swagger と UI を提供している。初めて connexion 使ったが便利だった。

今後追加したい(してほしい)機能

• Stream API で表示する
  • 実は awslogs-api の方はストリーム対応済み
• awslogs のパラメータへの対応
  • これも awslogs-api の方では対応済み。というかフロント書いてる途中に飽きた
• PWA または Local Storage を使った、ロググループなどのキャッシュ

社内ネットワークで使うための短縮URLサービス作った

社内専用環境とかで“性善説”に基いて運用できる、短縮URLを作ってみた。

github.com

詳細は README に書いているが、

• シンプルなUI
• 命名もできるし、ランダムな文字列もいける
• 既存の短縮URLの上書き(性善説だし :)
• DynamoDBがバックエンドで安い
• Dockerベース

ちなみに、イントラネットに置けるようにしたかったので、サーバーレスにはしてない。

モチベーション

Google社の勉強会とかにいくと、貼ってあるポスターに http://go/hoge みたいなリンクがあって(あるよね？)そういう“社内専用短縮URL”を実現したかった。

また、Slackのトピックには文字数制限があるが、どうしても制限を超える長いURLへのリンクを貼りたかったという事情があった。かといって、ここに貼りたかったリンクは社内専用の URL なので bit.ly とかの短縮 URL サービス使って短くするのも微妙だなということで作ってみた(例えば、社内のプロジェクト名などがURLからわかるのであまり出したくない)

技術スタック

技術的に新しいことをやりたかったので、Nuxt.js 使ってみた。１ページしかないので完全にオーバースペックだけど。

Nuxt.js は Vue.js の基本スタックを前提としていて(Vue, Vuex, vue-routerなど)、SSRとかもできるし、静的サイトジェネレータとしても使えてよかったし自分のウェブサイトとかも置き換えていきたい。

最近 Webpack 疲れみたいなことを考えて、 parcel とかも試したりしつつ、「Webpackの設定ファイルのメンテいらず」みたいなのは筋が良いんじゃないかなーと思ったりしている。

favicon

favicon は絵文字の「🔗」なんだけど、 Emoji Favicons | Favicon.io のサイトで生成したものを使った。とりあえず favicon 作りたいときには便利そう

Gif動画

GIPHY という Mac のアプリが使いやすかった。(教えてくれた同僚Nさんに圧倒的感謝 🙇)

あとがき

このOSSは定時に食い込みつつ作ったので宣伝しておくと、JX通信社ではサクッとモノづくりするのが大好きなメンバーを募集しています。

追記

ブコメありがとうございます。

CSRFの罠

CORSは考えていたのですが、CSRFは盲点でした；　気になる方はぜひPull Requestをお願いします！

DynamoDB使いたくない

Dockerベースで動くようになっているので、 dynamodb-local などで永続化することは可能で、実際 docker-compose では dynamodb-local を使っています。

現在は DynamoDB と密結合になっているので、MySQLやPostgreSQL、SQLiteなどがアダプターとして付け替えられるように設計を拡張すればいけるかなと思います。ぜひPull Requedstをお願いします！

また、「社内ネットワーク」という言葉がちょっとミスリーディングだったかもしれないですのですが、へーしゃはAWSを使っているのもあって「社内からしかアクセスできないAWSのネットワーク」を含めています。

年の瀬なので26歳の1年間を振り返る

「エンディングノート」書いた

あと60年くらいは生きたいが、遺言書を書いた。

友人や祖母が亡くなったりするイベントがあったので１年前くらいから書こうとは思ってて、この度生活環境が大きく変わったので(とても良い)、引っ越しに合わせて、書いた。「遺産を誰に遺贈するか」「寄付」「葬式・納骨」について記載している。

実は数十万〜数百万での遺産トラブルというのも多いらしく、若い人にもエンディングノートを書いておくのをおすすめしたい(僕はわりと勝手にお金が貯まるタイプなので、４年も会社勤めしてるくらいの資産はある。新卒からそうなので、今の給与とは特に関係ない)。ちなみに、未婚の場合、遺留分は親に行く。

僕が書いたのはコクヨの遺言書キットだけど、Amazonでエンディングノートとかでググると出て来て、結構カジュアルに書けるのでオススメ。

自分がこの１年で触った技術とか

この１年は、AWS、Docker、Python、Keras、サーバーレス、SPA、React、Vue、re:dash、ログ基盤、、、あたりを触ってた気がする。

特に去年に比べて新しいのは、SPA関連で、これは結構自分の身を助けた。社内サービス(XWire)の管理画面勝手に作ったり、プロトタイプツール作ったり。

DockerとSPA(特にVueは、楽だ。チーム開発には汚くなりやすいかもしれないが)は、「絶対にやった方がいい」と自信を持っておすすめしたいものだったりする。

来年はデータ可視化・分析周りと、SPA→アプリの分野(React Nativeなど)に殴り込みをかけたい。

あと、GoとRustにチャレンジしたい。

情報収集の方法

英語オンリーのアカウント作って、英語の情報アカウントとかをフォローしている。例えば、HackerNewsとか、海外の大御所とか、Github Trendingとか。はてブで入ってくる情報とはまた異なる種類の情報が入ってきて、大変良い。もっぱらこっちのアカウントをTwitterで開いている。

フォローしまくったら凍結されたりしたので(明らかに正しいTwitterの使い方なのだが...)Twitterのアルゴリズムは頑張って欲しい。。。

最近思うこと①：時間の使い方

とあるブログ記事で読んだ「定時が、ギョームでいっぱいだったら『忙しい』状態」という話は、「そうだよなぁ〜」と感銘を受けたりした。

暇ができたらイノベーティブになるのかは知らないが、仕事での意思決定・技術選択の根拠になるのは、たいてい、仕事以外で得た知識だったりする。むしろ仕事だけで得た知識で意思決定している人がいたら、絶対に信頼したくない。

であればこそ、定時内に「仕事」以外の仕事をぶち込んでいかないといけないし、定時外にプロジェクトを増やしていかないといけない。いわば、「トリプルワーク」を来年はしていけたらなと思っている(いわゆる副業ということではなく)。

最近思うこと②：会社との向き合い方

僕は、(生涯)年収の最大化を目的として、僕のキャリアを今の会社にベット(Bet；賭け)している、のだと思うようにしている。今日でちょうど、２年間をベットしたことになる(実際にはそれ以上だが、、、)

リターンの期待値を最大化するのであればそれなりの賭け方があるし、逆に、ポートフォリオを組むこともできる。

最近思うこと③

最近、あらゆる不便を「繋がっていない、という感覚」と自分の中で言語化している。この言語化が、この１年で自分にとって最も価値の高いものだったかもしれない。

例えば、アプリのマーケティングをしてお金を儲けようと考えたときに、アドネットワークで広告配信して、ユーザーがアプリをインストールし、アプリ内でアドネットワークの広告を見てマネタイズする。さて、「アドネットワークAを経由したユーザーで、いくら広告が儲かったか」が“直接”わかるかというと、わからない(少なくとも無料では)。「このアドネットワークでプロモーションするとROIが高いですね」ということを知りたいのに、繋がってない、という具合。

この「繋がってない」を解決できるサービスを作りたいなと思っていて、解決できると「マジで便利」なのかなーと思っている。とは言え僕は飽きっぽいので、それをどうマネージメントするかに苦心している。

Python の開発に VSCode を使ってみた雑感

普段 Python 書くときに使ってるエディター

• PyCharm (Vim Emulator を入れてる)
• たまに Vim

PyCharm の気に入っているところ

• 型推論がすごく良い。動的型付けな言語にとって、これはかなり良いメリット
• Vim の Emulator が結構良い

PyCharm の不満

• Vim の Emulator が入っているとはいえ、Vim じゃない
  • 例えばマクロがない
• 普段 Docker、 docker-compose を使っているが、Docker内のデバッグ(リモートデバッグ)は有償版でしかできない
  • 体験版使ったときは、動きすらしなかった。同僚によると今は大丈夫らしい
  • 会社の予算で買ってもいいんだけど、ホスト(mac) で Python 動かせばいいので買うほどじゃない
• direnv、flake8、mypy などのツール・ライブラリに対するサポートがない

VS Code の雑感

• リモートデバッグ使える、すごい
• 挙動がさくさく動く。Atomより気に入った
  • 特に、ユニットテストを関数ごとにやるというのがかなりやりやすい
• flake8、autopep8、mypy など外部ツールを最初から想定しているのが良い
• direnvもエクステンションで行けた
• 内部で ctags を使っているらしく、ctags 入れないといけないのにハマった(ドキュメントに書いてあった)

VS Code の不満点

• 型推論が弱そう
  • 大きいプロジェクトだと、mypy のサポートもあんまり上手くいかない。設定が悪く import がうまくいってないのかもしれない。。。
• PyCharm にある

VS Code のリモートデバッグ

• 問題なく動いて感動
  • 自分は Docker 内でしか試してないが、恐らくリモート環境にあるサーバーでも動くだろう
• 最初はセットアップがちょっと面倒くさい
  • ptvsd を Docker 内でインストールしないといけない
  • docker-compose の command で pip install ptvsd && python hoge.py した

VS Code の Vim Emulator

• マクロが動く！すごい！
• キーバインドが設定できないものがある。例えば、 vi( みたいにビジュアルモードに関係するやつが設定できなかった
• .vimrc は読めないので個別の設定が必要
• 一部の Vim プラグインにネイティブで対応してるっぽいのがすごい

総評

• PyCharm に比べて、 外部ツールに対応しているのがすごく良かった
• リモートデバッグできるのも良い
• けど、型推論系が弱いのと、自動の import がなくてつらいのを解消したい

こうして人は拡張機能を作るのか。。。

「GraphQLは何に向いているか」に対してのちょっとした反論

k0kubun.hatenablog.com

非常に丁寧に書かれていると思うのですが、少し反論したい部分があるので、記載したいと思います。

GraphQLのキャッシュ効率について

クエリをパースしないとキャッシュの可否を判定できないため、HTTPキャッシュが難しい

こちらに関して、２つの観点から反論してみたいと思います。

まずに、GraphQL は GET リクエストでも送ることができます。Serving over HTTP | GraphQL によると、http://myapi/graphql?query={me{name}} のような URL の GET リクエストができます。(※そもそも、これ自体は GraphQL の絶対的な制約ではなく、 GraphQL を一般的に HTTP で提供するときのプラクティス、という位置づけです)

そして、GraphQL は 1 回のリクエストで送らなければならないわけではない、ということです。

私は JX 通信社 で NewsDigest というニュースアプリを作っています。例えばニュースアプリであれば、「フィード」というキャッシュ効率の高いものあれば、「ユーザーの設定」というキャッシュできないものや、書き込むものもあります。このような例であれば、キャッシュ効率の高いリクエストとキャッシュ効率の低いリクエストをわけ、さらに mutation の操作のみ POST リクエストを送れば、CDNなどでもキャッシュ可能です。

これは REST API であれば、 GET /feed と GET /settings と POST /settings というリクエストにわかれるわけですが、 GraphQL の方が特別キャッシュしづらいというわけではない のではないかと思います。(※もちろん、リクエストをわけると GraphQL のメリットは下がります)

弊社がGraphQLを採択してみた理由

厳密には採用したものをリリースしようとしている段階ですが、弊社で GraphQL を採用したかった理由を述べたいと思います。

GraphQL に感じる大きなメリットの１つは、API と型とドキュメントがパッケージ化されている ことです。もちろん、 JSON Schema や API Blueprint を組み合わせることもできます。しかし、これがパッケージ化されていて、「GraphQL」という技術の標準規格であり、後付けの技術ではないというのは大きなメリットだと思います。「GraphQLのドキュメント読んどいてください」「GraphiQL触ってください」で話せるわけです。

もう一つは、 GraphQL はクエリが定数であり、「どうリクエストするか」を定数化できる というところです。このメリットが触れられていることを見たことがないのですが、これは GraphQL にしか解決できない(?)大きなメリット だと思います。「定数化」というのはどういうことかというと、 { hoge { fuga, piyo } } みたいな「どのオブジェクトを取得し、このフィールドが必要である」という情報を「定数」として、Android、iOS、Javascript、サーバーサイドで共通化できる、ということです。例えば「アプリ立ち上げ時にはこのリクエストを送って下さい」という指示を、クエリ定数 として、各プロジェクトで共通化でき、サーバーサイドのスナップショットテストでクエリの互換性を担保したり、、、みたいなこともできます。

※ 「クエリを定数化」と書いてしまったのですが、クエリ自体が定数なので(その代わりに引数や変数の概念がある)、表現を修正しました

逆に、Github や Facebook のようにリソースが多かったり、サーバーサイド開発者がクライアント側を書いたりは(あまり)していません。

また、キャッシュ効率について「CDNでもキャッシュできる」とは述べたのですが、フィードのパーソナライゼーションなどが必要になるので、採用していません。

個人的に考えるGraphQLの大きな問題

クエリのパースが複雑なため、ライブラリ依存になる、という点です。

例えば、2017 年 9 月現在、 Python の GraphQL ライブラリには次のように書いてあります。

This library is a port of graphql-js to Python and currently is up-to-date with release 0.6.0.

0.6.0 は 2016 年 5 月の実装です。「各言語ごとの GraphQL ライブラリが対応してないものには対応できない」という潜在的な問題を含んでいることになります。もちろん、OSS なので Contribute すれば良い、ということでもあるのですが。

もう一つ、一般的に HTTP 上の GraphQL のレスポンスはオブジェクト(連想配列)を返すので、でかい配列データ(ニュースフィードなど)を JSON Streaming でインクリメンタルに表示する、みたいなのが難しいんじゃないかなーと思ったりもします。

GraphQL を採択すべきでない理由をあげるなら

GraphQL は、あまり何かを制限するものではありません。 RESTful API のように使うことも一応可能です。

したがって、「GraphQLを使うべきでない」というケースというのは「RESTful API のような使い方ぐらいしかしないからオーバーエンジニアリングだ」というときなんじゃないでしょうか。

まとめ

• GraphQL は何か制限をするものではない
• GraphQL は型やAPIドキュメントをパッケージ化していて、クエリを定数として共有できるのもメリット
• GraphQL が適さないケースは確かにあるが、キャッシュは問題ではないと考えている

GraphQL がもっと広まるとうれしいです。3 年後には「何だったのか」って総括されてそうですけど。笑

以上です。

補足

ブコメありがとうございます！

id:koyancya

定数クエリ、REST のエンドポイント増やすのとは何が違うのだろうか

ニュースアプリとかの場合を想定して、例えば、アプリの立ち上げ時に「トップのフィード」「ユーザー設定」を同時に読み込みたいとします。これはGraphQLでは次のように表現できます(※実際には引数や変数を宣言しますが、クエリ自体は定数です)。

GET /graphql

{
  feed {
    title, createdAt
  }
  setting {
    subscription, prefecture
  }
}

一方で、GraphQL でない場合、これを「定数」として縛ろうとすると、次のようなエンドポイントを生やす感じになってしまうかなと思います。

GET /app_startup

これでは、そもそも RESTful ではなくなってしまいます。また、「やっぱり立ち上げ時は、ユーザー設定読み込むのやめよう！」となったとき、API側を変更する必要が出てきてしまいます。GraphQL の場合、リソースを宣言してさえおけば、フロント側だけでリクエスト方法を固定できます。(で、答えになっていれば良いのですが・・・！)

Puppeteer を CLI で動かす Docker イメージ作った

また新しい Docker イメージ作ったので紹介する。

https://hub.docker.com/r/yamitzky/puppeteer-cli

Puppeteer とは？

github.com

Chrome Headless を Node で触るためのライブラリで、URLを見ると分かる通り、 Chrome のチームが出しているものです。

Puppeteer-CLI は？

Puppeteer を CLI から動かす、 Docker イメージです。現在は、スクショを撮る機能のみ対応しています。

Chrome Headless そのものを Docker で動かすのに比べてのメリットは、

• Docker での連携を前提にしていて、 標準出力にスクショ結果を吐き出すことができる ※Base64エンコードされています
• CSSを埋め込めるので、日本語フォントとかも行ける
• 今後の発展性 ※ 現在は未対応ですが、今後 puppeteer のコードを実行できるようにしたいです。

使い方

標準出力に吐き出すときは、

docker run -it --rm yamitzky/puppeteer-cli --url https://yamitzky.com

日本語対応するときは、

docker run -it --rm -v "$PWD:/tmp" yamitzky/puppeteer-cli --url https://yamitzky.com --out /tmp/example.png --delay 1000 --css 'https://fonts.googleapis.com/earlyaccess/notosansjapanese.css' --style 'font-family: "Noto Sans Japanese"'

といった感じで動かせます。 Noto フォントシリーズは、韓国語とか中国語にも対応しているものもあるので、読み込ませるCSSの設定を変えればいろいろできます。

Options:
  --width   Width of viewport
  --height  Height of viewport
  --out     File path to save. If `-` specified, outputs to console in
            base64-encoded                                        [default: "-"]
  --delay   Delay to save screenshot after loading CSS. Milliseconds
  --css     Additional CSS URL to load
  --style   Additional style to apply to body
  --url                                                               [required]

Examples:
  index.js --url=https://example.com

なんで標準出力に吐き出せると嬉しいの？

だいたい、こんな感じの使い方をイメージしています。

ECSの場合、標準出力に吐き出されたログを、CloudWatch Logsに出力することができます。CloudWatch Logs から Lambda を発火させて、 Lambda から Slack に投稿したりできそうだなーと思った次第です。