病みつきエンジニアブログ

機械学習、Python、Scala、JavaScript、などなど

API と SPA からなるプロジェクト(JAMstack)を作るベストプラクティス

背景

サーバーサイドの人がフロントエンドを結構こだわったプロジェクトをやるときに、混乱することが多そうなので、(社内向けに) 自分がいろいろ作ったなかで思ったベストプラクティス(？)を共有する

用語

もう少しちゃんとした説明は、各キーワードでググって下さい。

サンプルリポジトリ

https://github.com/yamitzky/nuxt-api-example

実装は分割してプルリクエストにした

前提

プロジェクト全体の前提としては、

  • 「SPA と API」という構成にする
  • フロントエンドは Nuxt などのレールに乗せる
  • (ほぼ)同じオリジンとして扱う

そもそもフロントエンドは独立したコードベース (≒ SPA) にしたが良いのか？

例えば管理画面を作るときなど、例えば Django や Rails などで SPA ではない構成を取ることが多いと思う。ケースバイケースだが、フロントエンドを独立したコードベースの SPA にすると下記のようなメリットがある。

  • フロントエンドのコードが複雑になったとき、破綻しづらい
    • コンポーネント指向な設計になる
    • Flux なり Vuex なり、状態管理の設計が強制される
  • フロントエンドのエコシステムに乗っかれる
    • ホットリロード
    • エディタサポート
  • JAMStackのメリットが得られる
  • ようするに餅は餅屋

ただし、 qrunch.io は Rails と turbolinks ではあるが、SPA のようなサクサクしたユーザー体験を提供できている、という例もある。ので、結局好みでは。

ディレクトリ構成

ディレクトリは次のような構成にする。api 以下は Python とかの世界。frontend 以下は Nuxt とかの世界。「frontendプロジェクト」と「apiプロジェクト」の２つのリポジトリがあるモノレポみたいなもの。

こうすると、Docker のイメージが効率良く作りやすくなる、それぞれのホットリロードが正しく効くとかのメリットがある。

project
├── api
└── frontend

配信構成

nginx、api の２つのコンテナから成り立たせる。

nginx (example.com)
  -> /api/* -----> api のコンテナ
  -> それ以外 --> 静的ファイルとしてフロントエンドを配信

あるいは、静的ファイルは CDN にデプロイする

example.com ------> CDN 上で配信
api.example.com --> api のコンテナ

JAMstack としては、静的ファイルは CDN に乗せるのが良さそうなんだけど、SSR ができないというデメリットもあるので、どちらでも良さそう。(パフォーマンス要件などに応じて適当に考える)

ここで大事なのは、*Django などの API 側フレームワークは一切の静的ファイルを配信しないこと。JSONを吐き出すのが責務

開発時の配信構成

docker-compose などで、 frontend のコンテナと api のコンテナがある想定

frontend (localhost:3000)
  -> /api/* -----> http://api:8080/* をプロキシ
  -> それ以外 --> frontend のプロジェクトとして普通に配信

あるいは、docker-compose を使いたくないなら

frontend (localhost:3000)
  -> /api/* -----> http://localhost:8080/* をプロキシ
  -> それ以外 --> frontend のプロジェクトとして普通に配信

frontend のプロジェクトには、たいてい、開発用にプロキシする機能がついている(nuxt, vue-cli)。

デバッグするときに見るのは、 localhost:3000 だけ。そうすると CORS とか Cookie の問題が解消するので、ハッピーです。

Nuxt 使おうぜ話

概ね、 Nuxt のレール乗っかっておくと非常に楽。

  • 設計が強制される
  • SPA のために必要な機能が揃ってる
  • store のモジュール化なども自動で対応してくれて便利
  • ~/hoge でアクセスできたりして便利
  • SSR も対応
  • ビルドパイプラインのメンテが簡易

もちろん Nuxt 以外のレールでももちろん良いが、 Vue は easy と言われることもあり、学習コストが低めで良いのではないか、というスタンス。

認証

Nuxt の認証はだいたい３パターンぐらいあって、

セッションや JWT を使うのは、Nuxt じゃない技術選定をしても、だいたいそれらをどう保持するかという話になりそう。localstorage かセッション、Cookie に保持する。

TODO

  • PWA、キャッシュ

おまけ：環境変数とか

  • yarn
  • pipenv
  • .env
  • direnv

を使っている。

サンプルプロジェクトだと、あえて .env と .envrc をリポジトリーに追加している。

.env と direnv の使い分けは、

  • .env: 環境変数を定義する。 JetBrains 系、VSCode などのエディターが .env をサポートしているため
  • direnv: .env に定義された環境変数や、pipenv --venv で得られる環境変数をロードする。.envrc には、環境変数の定義自体はしない
# .envrc

source `pipenv --venv`/bin/activate
export `cat .env`

WEB+DB PRESS サーバーレス特集で伝えきれなかったことの補足

先月、WEB+DB PRESS vol.105の特集「サーバレス」にJX通信社のメンバーとして寄稿いたしました。

紙面の都合上、泣く泣く削った部分もあったりして、伝えきれなかったところがあります。Twitter 上でもらった質問などもあるので、いくつか補足します。

tech.jxpress.net

紙面では「サーバレス」という表記で統一したのですが、以降は「サーバーレス」という表記を取ります。

サーバーレス特集の意図

サーバーレス特集で特に意識したのは、次の２つです。

  • 「実務」としてはどうあるべきか
  • 「サーバーレス」というものに共通する本質

「実務でどうあるべきか」というのは、「サーバーレスで作る」といっても結局は「システム開発」である、ということです。システム開発であれば、当然チーム開発になりますし、ユニットテストだったり、ローカル環境の整備だったり、監視やCI/CDだったりが担保されている必要があります。そして、システムとしては特定の環境に依存するべきではないです。サーバーレス特集は、そのあたりの観点を重要視して構成しています。(特に後半の章が関係してきます！)

そして、Firebase特集がかぶってるという事情もありLambdaを題材にしてはいるのですが、「サーバーレスそのものの本質」というところを意識しています。「AWS Lambda」でもなく「Firebase Cloud Functions」でもなく、「クラウド」ですらなく、「サーバーレスそのもの」の話です。そのため、第一章では、クラウドではないオープンソースなサーバーレスについて触れています。

「実務でどうするか」と「サーバーレス自体の本質」というのは、既存の入門書・入門記事にはないメリットを目指しています。そのため「すべてのユースケースに対応する１冊」ではないかもしれません。

サーバーレスの本質とは何か

「サーバーレスとは何か」を説明するのは、毎回悩むのですが、理論上は常駐プロセスが存在せず、リクエストに応じたキャパシティを必要なだけ柔軟に確保するものという定義が一番近いと考えています。クラウドである必要はなく、ただ、そういうアーキテクチャーで作ってればクラウドベンダーがPaaSを用意するのが必然的であるというだけです。そして環境としては「ただの使い捨てのLinux*1」です。

しかし、実際のところは、サーバーレスには関連する技術領域があります。安価にシステムを作れるものであり、スケーラビリティの救世主であり、クラウドに依存するものであり、マネージドサービスの玉突きによってアーキテクチャーを作るものであり、マイクロサービスを突き詰めたものであり、Twelve Factor AppやIaaS->PaaS->BaaSの進化の果てでもあります。しかし、このあたりは話題として広くなってしまうため、深掘りできていない部分でした。

サーバーレスやLambdaは具体的に何に使えるのか

こちらはTwitterで質問をいただいたものです。

答えとしては、処理が短時間で完了するものであれば、何でもできるとなります。「ただの使い捨てのLinux」だからです。

例えば、Lambdaを使って機械学習することもできるし、Lambda上で(対応してない)ScalaやRustを動かすこともできます。APIだけじゃなくHTMLを返したりもできますし、ニュースの解析エンジンだったり、特集に書いたようなログ基盤もできます。

ただし現実的には、次の３つの用途が多いでしょう。

  • 安価に、まあまあスケーラブルなAPIを作る
  • 安価に、5分以内で終わるバッチ処理をする(cron 的な)
  • AWS や GCP のサービスに関連した処理をする

cron 的なバッチ処理や AWS との連携に関しては、Engineer Hub に寄稿した「ウェブサイトやデータベースの監視」というのが参考になると思います。

employment.en-japan.com

ログ基盤の可視化

こちらはさらっっっっっとだけ触れたのですが、Redashを使っています。

ECS に作った Docker クラスター上にデプロイしています。

tech.jxpress.net

そして、Slack 上で KPI の変動を監視しています。(参考：Gunosyデータ分析ブログ)

Redash やログ基盤周りは永遠に語れる気がするので、語りたいですｗ (ちなみに、すでに収まらなかったのでこの章は増ページしています)

おわりに

サーバーレス特集で伝えきれなかったところを書きました。

すでに読んでいただいた方で質問があったら、 @yamitzky までお願いします。

もしまだ読んでない方がいたら、お買い上げいただけたら幸いです。

gihyo.jp

*1:とかのOS

マスコミの方にも知ってほしい、仮想通貨とCoinhiveの話

Coinhiveというスクリプトを設置していただけで逮捕されるという事件が起きていて、マスコミなどでも報道されています。

www.sankei.com

マスコミには読者の方に伝わるように伝えるというミッションがあるので、報道の表現が正しい・正しくないという話にはいろいろな立場があり、致し方ない部分があると思います。

しかし、仮想通貨やCoinhiveは、マスコミにとって「対岸の火事」ではなく、メディアのマネタイズに対する解決策となりうる技術 でもあります。報道ベンチャーのメンバーの端くれとして、仮想通貨やCoinhiveの技術がなぜメディアにとって潰されるべきではないのか、Q&A風に伝えたいと思います。

前半は仮想通貨に関する導入から入り、後半でCoinhiveの話をします。
また、個人的なポリシーにより、以降は仮想通貨を”暗号通貨”と呼称します。
報道機関の方に伝わることを目的としているため、もしかしたら厳密でない表現があること、ご容赦ください。報道機関やメディアの方で、何か不明点があれば、Twitterか会社のメールアドレスまでご連絡いただければ回答します(gmailはだいたい見逃すのですみません...)。

“通貨”とは？

暗号通貨の話をする前に、”通貨”の要件について考える必要があります。

最も普及した通貨は、日本円のような現金です。現金は、誰かに手渡すことで購買の手段として使うことができます。1000円札を持っていれば、「小笠原は1000円札を持っている」と、国や周りの人が認めてくれます。

では、銀行口座はどうでしょうか？ 銀行口座も、家賃を支払う手段として使えますし、口座に「1000円」と書いてあれば、やっぱり「小笠原は1000円を所持している」と認められます。また、持ってる1000円を別の誰かに送金することもできます。

では、楽天ポイントやAmazonはどうでしょう？ これもだいたい似たようなもので、楽天ポイントは楽天市場での支払いに使えます。1000pt持ってたら、（実質的に）1000円分持ってることになります。ポイントが失効しない限りは、突然ポイント残高が消失することもありません。

ここで、現金、銀行口座、ポイントの例を上げましたが、これらはいずれも「通貨のようなもの」でしょう。「通貨のようなもの」は、何かの決済手段として使えたり、誰かに送金できたりしたりできますし、消費しない限りにおいては残高が消滅することもありません。そして、「1000円持ってるんだな」ということが保証されるものです。こういった、「正しく送金の帳尻が計算できること」「正しく残高が保証されてること」「決済に使えるなど、日本円と融通できるような価値があること」が”通貨”にとっては大事なのです。逆に言うと、日本円とかドルとかユーロだけが通貨としての役割を果たせるわけではなく、先に挙げたような条件を満たせるものであれば、買い物券だろうと肩たたき券だろうと、通貨のようなものになれます。

暗号通貨とは？

暗号通貨は、先程あげた”通貨”の特徴を持ったものの１つです。ちょっと特殊なポイントのようなもの、と言い換えてもいいでしょう。

暗号通貨が特殊なのは、「誰が残高があることを保証するのか」という違いです。日本銀行券の場合は、日本銀行が保証してくれます。銀行の口座残高の正しさは、銀行が保証してくれます。Amazonのポイントは、Amazonが保証します。

暗号通貨の場合は、「みんな」が保証します。銀行のような単一の信頼できる誰かが保証するのと違い、みんなで保証するのはとても大変です。そのため、技術的には暗号などに使われる要素技術が使われていて、「暗号通貨(Cryptocurrency)」などと呼ばれるのです。

「みんな」で保証するのはとても難しいので、「マイニング」というプロセスで解決します*1。

マイニングとは？

マイニングとは、「みんな」で残高の正しさを保証するために必要な仕組みです。

たとえば、誰かが「僕は100万円受け取った」と主張した場合、どうやってそれが正しいかを確認すればよいでしょうか？ 銀行の残高であれば、銀行のログに送金履歴が残ってるので、銀行の人が保証できます。ですが「みんな」で保証する場合、みんなが好き勝手言えてしまうのです。

そこで、「マイニング」に成功した人が言ったことが正しい、と「みんな」で認めるルールとします。

「マイニング」とは、物凄く難しい計算問題をコンピューターに解かせることです。「マイニング」は答えを見つけるのは難しいのですが、答えが正しいことは簡単にわかるような問題なのです。ちょうど、「鉱山から金塊を見つけるのはとても難しいが、それが金塊であることは誰しもわかる」といった具合でしょうか。そして、「金塊を持ってる人が言ったことを、10分間だけ信じよう」というルールになってます。

マイニングをコンピューターにやらせるのは、計算コストがかかります。つまり電気代がかかるということです。なので、マイニングはボランティアでやるものではありません。代わりに「マイニングをすると儲かるよ！」という仕組みが暗号通貨には含まれているのです。

「マネタイズ」という視点で見たときにマイニングが革命的なのは、「マイニングという、ただコンピュータープログラムを走らせること」がお金儲けに繋がるというロジックが生まれたことです。

Coinhiveとは？

Coinhive とは、マイニングを、Webページの閲覧者に代わりにやらせる仕組みです。通常マイニングは「自分が儲けるために、自分のPCで実行する」ものですが、Coinhive は「自分が儲けるために、ユーザーのPCで実行する」ための仕組みです。

こう聞くと「人のPCで勝手に金儲けしやがって」と思うかもしれませんが、それがビジネスです。ウェブ広告だって、99%の人に価値のないバナー画像や動画をダウンロードさせ続けることで、メディアは儲けられるのです。メディアが儲けられることで、読者に面白いと思ってもらえる体験を提供できるのです。読者の直接支払いだけでビジネスが成り立てばそんなに嬉しい話はないですが、現実は違います。

Coinhiveは、広告に勝るメリットがあります。その一つは、ユーザーの個人情報を収集するインセンティブがないことです。ウェブ広告はユーザーの個人情報を集めるほどPV単価が高くなりますが、マイニングには個人情報は使えません。マイニングが広告に比べて悪質かどうかは、極めて微妙なラインです*2。

また、Coinhive は「どれくらいCPUを使うか」を指定することができます。CPUを100%使うか10%しか使わないかは、各設置者が勝手に決めることなので、ダメージを与えない方法も可能なのです*3。

f:id:yamitzky:20180615091620p:plain

なぜCoinhiveはメディアに関係するのか？

メディアにとっての一番の課題は「どうやって儲けるか」です。テレビだろうと新聞だろうとウェブメディアだろうと同じ問題です。Coinhiveは、サブスクリプションやウェブ広告に続く新しいマネタイズ手法になる可能性があります。

中でも驚異的なのは、Coinhive は、記事をただ閲覧していることで収益が発生することです。広告は、広告主を集め、その広告に効果がないと意味がないのですが、Coinhive にそのような問題はありません。また、閲覧時間が長ければ長いほど儲かるので、閲覧時間というメディアの本質的なKPIと、収益性がリンクしています。

ただし、Coinhive は現状そんなに儲かる手段ではない、ということは言っておく必要があるでしょう。

なぜ Coinhive の設置者の逮捕が、メディアにとって問題なのか？

「社会的に受け入れられてない」ことを理由に、既存の法律の拡大解釈の元にターゲットとされ、メディアのマネタイズ手法が刑事案件で潰されたり、民間企業によって「ウィルス」として定義されて潰されることが問題なのです。

例えば、アウトブレインのようなレコメンドウィジェット広告と呼ばれる比較的新しい広告があります。これらがどういった処理を行っていて、どういう情報が収集されているのか、全てのユーザーは十分に理解しているでしょうか？ Criteoとかもなぜリタゲされるのか理解されてるでしょうか？ これは、さすがに現実的ではない話です。「同意を得ていないのだから逮捕は当然だ」というのはそういう暴論なのです。

また、広告のようにユーザーには見えず、“こっそり”やるから問題だ、という意見もあります。しかし、広告と違ってマイニングスクリプトが見えないのは、ブラウザーの実装の問題に過ぎません。高負荷のスクリプトや、coinhive.js がユーザーに見えないのは、2018年6月現在のブラウザーの実装の話です*4。そもそも coinhive.js がダウンロードされていることはブラウザーは知っていて、開発者ツールなどにはちゃんと表示されているのですが、ただわかりやすいところに可視化していないだけです。このようにブラウザーの実装の問題で可視化されてないプログラムは、 coinhive.js に限った特殊なものではなく、ウェブサイトに一般的なものです*5。

たしかに、ユーザーの理解を可能な限り得ることが理想です。Coinhive にしても広告にしても、ユーザーに説明した方がベターでしょう。そういう説明を怠れば、「炎上」して、ユーザーに忌避されるでしょう。ですが、これは「動画広告」や「リタゲ広告」のような新しい広告と同様、ウィルスと認定して逮捕する話ではなくて、市場が決める話です。

まとめ

本稿は「マスコミの方に伝えたい」という思いで書きました。

仮想通貨やCoinhiveのような新しい技術がどうやって社会やメディアビジネスに良いインパクトをもたらすか、というところで記事の執筆に役立てていただければ幸いです。

*1:ビットコインやモネロに関してはこの通りなのですが、マイニング以外の方法もあります。PoSと呼ばれるような仕組みの暗号通貨です。

*2:パケットを消費しないというメリット表記にツッコミがありましたが、厳密にはWeb Socket通信などでパケットを消費するものであり、長時間稼働させれば画像や動画以上にパケットを消費しうるものであるので不正確なため、表記を削除しました

*3:もちろん、ユーザーのコンピューターを攻撃して破壊する目的で、100％のCPUを利用するのは問題があります。ですが、ブラウザーのタブを閉じることによって、ユーザーはプログラムの実行を終了することができます。

*4:既存のブラウザーでも、アドオンなどを入れることで、coinhive.js が読み込まれていることを検知することができます。すでにユーザーにはブラウザの選択肢があるのです。

*5:例えば、今ご覧になっているページでは、はてな株式会社が設置し、ユーザーに対して能動的で明確な許諾をとっていない、目に見えないJSのプログラムが動いています

Lambda 用にネットワーク通信を楽にするための Python ライブラリ作ったら捗った

Python

Python で通信するとき、公式の urllib の使い方を覚えられないので requests を使いたい。

だけど、AWS Lambda みたいな環境だと、外部のライブラリを pip install して使うのが面倒くさい。zipで固めてアップロードしないといけなくて、Lambda関数を管理画面で簡単にいじれる感じではなくなってくる。

そこで、requests とだいたい同じような使用感の通信ライブラリを、120行ぐらいの1ファイルで書いた。

github.com

だいたい同じようなAPI↓

# 本家
import requests
requests.get('http://example.com')

# 1ファイル版
import req
req.get('http://example.com')

1ファイルなので、pip install はする必要がなくて、適当なファイル名でコピペすれば良い。

f:id:yamitzky:20180518000321p:plain

requests 風に使えるので、Slack への投稿とかも簡単にできて捗る。

import req
import time

def lambda_handler(event, context):
    req.post('https://hooks.slack.com/services/xxxxx/xxxxx/xxxxx', json={
        'text': 'ああああああああ'
    })

あくまで 120 行ぐらいの簡易版なので、UTF-8にしか対応してなかったり色々あるが、簡単な使い方であればこれでいけそう。

「1ファイル」の設計思想的としては bottle を参考にしてて、bottle も 1ファイルで作られていたりする、すごい。

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

タイトルは釣りです。

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

経緯

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

f:id:yamitzky:20180212180912p:plain

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

f:id:yamitzky:20180212182706p:plain

ちなみに何故「ドル」表記がツイートの画像に付いていたかというと、実際に 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

screenshot

コンセプト

先行アプリケーションとして 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

demo

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

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

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

モチベーション

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

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

f:id:yamitzky:20180110210156p:plain

技術スタック

技術的に新しいことをやりたかったので、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のネットワーク」を含めています。