買ってよかった Kindle Oasis

課題感

読書量を増やす必要性があって、「追加のお金を払ってでも、本を読みたい」というのがあって、色々な方に相談した結果 Kindle Oassis を買ってみました。8GB、広告なしモデルです。

Kindle Oasis、電子書籍リーダー、防水機能搭載、Wi-Fi、8GB

完全なリアル書籍派だったんですが、結果的には Kindle Oasis 買ってよかったです。

購入理由：電子書籍でしかできない体験がありそう

• お風呂でも読める
• 夜、ベッドで電気が暗くても読める(バックライトがある)
• 暗い夜道でも読める
• 片手で読める
• ポケットに入る
• 机に置いて食事中に読む
• カバンに複数の本を入れる

「スキマ時間で読む」というのができるようになって、1日あたりの読書スピードがすごく上がった感じがある。

ある程度大きな本(例えば最近だとHacking Growth読んだ)は、机の上に置いて読んだり、片手に持って読むのは難しい。けどこれが Kindle だと楽にできるので嬉しい。

事前の懸念

1. 会社の経費で本を買えない

今回は「お金を払ってでも読むこと」に重きを置いたので妥協した*1

あと、ちょろちょろ寄稿とか登壇の収入があるので、そっちに関係しそうなものはそっちの経費につけようかなとも思っている。

2. 良かった本を他の人に貸せない

「貸す必要があったら、会社の経費で買って渡せばいいや」と思って解決した。貸す相手は会社の人が多いし。

3. 技術書読みづらい説 (まだ遭遇してない)

PCで読んだりして使い分けると良いとのこと

結論

買ってよかった Kindle Oasis。

*1:会社経費で本を買える制度があるんですが、開発に直接関係しないビジネス書とかだと、ちょっと抵抗あって普通に自腹で買ってたりもします

2018 -> 2019

振り返りと、ささやかながら今年の目標を。

アウトプット編

WEB+DB PRESSとエンジニアHubの寄稿、デブサミとDevelopers Boostの登壇があって、大変だった(小並感)

こういうのって、「誰に対して何を伝えたいのか」が本当に難しい。例えば、PyConでPythonの話するときは「Pythonを知ってる人」に対して伝えればいいだろうけど(中級者向けと宣言した上で)、汎用的なカンファレンスだと「コンテナって何」って人も「Docker使ってます」って人もオーディエンスに含まれるので、抽象(お気持ち)→具体(テクニック)に話を展開する必要がある気がして、なかなか慣れない。

仕事編

執行役員/VPoEになった。転職のオファーを何件かいただいたのもこのあたりで、意識的に自分のキャリアを選ぶのって大事だなと思った。会社のステージがさらに進むまでは同じ理由で断るかもしれない。知らんけど。

マネジメント的仕事が多くて、あんまりプログラムが書けなかったのが心残り。ただ、マネジメントは「仕事として」楽しい感じはあって、嫌とは明確に違う。前職では業務委託2〜3人＋正社員エンジニアがマネジメントみたいなチーム編成で、それが嫌で転職したところもあったけど(※その方々は本当にいい人で転職してからも飲んだりしてる)、その人数を超えるとマネジメントの目的が変わってくるので、楽しい。

12月は他社のマネジメントの方と飲む機会があり「なるほど〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜」となったり、他社の開発のミーティング参加させてもらって「なるほど〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜」となったりしたので、そういう機会を増やしていきたい。あともっとコード書きたいね。

買い物編

• GoPro
• 分割キーボード
• iPhone Xs
• Philips Hue

いい買い物であった。分割キーボード壊れたけど。悲しい

GoProはダイビング用に買ったけど、日常使いでも、友人のライフイベントを広角で撮れるのってすごい素敵だなって思った。光が暗いとあんまり役に立たないんだけど。

↓石垣旅行で一番気に入った一枚

本編

ダントツで「ブランディングの科学」が面白かった。エビデンスのない話に結構飽き飽きしていたけど、その点科学的で良かった(もちろん科学的に批判される余地もあり、書評では賛否両論っぽい)。自分は科学的なアプローチ好きなのかもしれないので、ノーベル賞取った人の本とか読もうかなと思っている。

食べ物編

• 初めてペアリングのコース
• 初めての日比谷ビアフェス
• 初めての牡蠣を食べるホームパーティー
• 初めてのチェアリング

ペアリングとチェアリングは似て非なるもので、屋内で料理に合わせてワイン飲むのがペアリング、屋外で好きなところに椅子置いて飲むのがチェアリングです。

牡蠣はこちら。

manualog.net

旅行編

• 河口湖キャンプ
• 山梨旅行
• 開発合宿＠秩父
• 石垣島旅行

↓渾身の一枚「隈飲み」

石垣島は２回めだったけど、初スキューバダイビングとか、初ジェットスキーからのシュノーケリングとかが楽しかった。今年は一人で旅行行きたい。

プライベート編

• 結婚式４回ぐらい行った
• 会社の同僚とボードゲームいっぱいした
• 朝まで飲むのいっぱいした
• 花火見た
• 合コンした

振り返ると、これが噂の結婚ラッシュか・・・ってなる

↓マンション・オブ・マッドネスおすすめです

結婚式では 結婚パーティーのため Nuxt と Firebase でサーバーレスなご祝儀を納品した話 - 病みつきエンジニアブログ とかもやった。

2018年振り返って

Google Photos見ながら振り返ると、めっちゃ充実してるじゃん!!!!!!!!!ってなった。こんなに楽しかったのか2018年。Google Photos マジ偉大だな。今年も良い一年にしていこうな

2019年の目標

来年の豊富は「絶対に一杯目にビールを飲まない」です

— やみつきー(小笠原みつき)＠ 76.2kg (@YAMITZKY) December 31, 2018

ここで言うビールは「とりあえずビール」のことで、ビール飲みたくなくても頼むのは意志薄弱だし、プリン体摂取だし、良いことないなって。クラフトビールとか「飲みたいビール」は飲む。

あと2018年は学生時代のこと思い出した。知らない人とゲーム作って、知らない人と起業し。。。みたいな謎のテンションが学生時代はすごかったので、そういう感じで生きていきたい。

今年もたくさん泥酔すると思いますが、そのときはどうぞよろしくおねがいします。

結婚パーティーのため Nuxt と Firebase でサーバーレスなご祝儀を納品した話

この記事はNuxt.js Advent Calendar 2018の10日目です。

友人の結婚式の二次会向けのコンテンツとして、 「ニコ生」風に投稿された写真やコメントが流れるシステム を作りました。

動画だとわかりづらいかもなのですが、広いパーティー会場で、リアルタイムにプロジェクターで写しているような感じです。

ユーザーが写真投稿するページや、プロジェクターで写すためのニコ生風ページに Nuxt.js を使っていて、Firebase Hosting 上で SPA としてホスティングしています。デザインは @aixcheck が作ってくれました*1。

つまり、Nuxt と Firebase で作っている、完全にサーバーレスなご祝儀です*2。ちなみにご祝儀ドメインも取得しました。

こちらのシステムのソースコードは、一部を除いてオープンソースにしています。pages や components は公開していないので、プロジェクトとしては動かないのですが、Firebase や Nuxt での TypeScript の参考になれば幸いです*3。

github.com

システム概要

Nuxt.js と Firebase (Hosting, Cloud Firestore, Cloud Functions, Cloud Storage) を使っています。

ブラウザから、Firebase SDK を介して Cloud Firestore や Cloud Storage へ直接書き込むようにしています。写真に関しては、Cloud Storage 上に写真が保存されると Cloud Function が立ち上がるようになっており、その中でImageMagick を使って写真を小さく加工した上で Firestore を更新しています(参考)。

写真を加工して小さくしている理由は２つあり、1つは iPhone で撮影すると90度回転してしまう問題の対処、もう1つは特設ページをスマホで見たときに、ギガが減らないようにするためです。

FIrebase の選定はかなり早いうちに決定しました。

• リアルタイム性
• なるべく固定費用がかからないようにしたい
• 0人〜100人規模でなるべく速くスケールする

などが理由です。AppSync も検討したのですが、DynamoDB が「結婚式以外の日に、データベースの固定費用がかからない」という要件を満たせなかっために外しました。Firebase に障害が起きていたら動かなかったので、なかなかリスキーな選択だったと思います。。。

Nuxt の方

Nuxt.js でページを作るにあたって、初めて TypeScript を導入してみましたが、いくつか大変なところがありました。

• Nuxt.js で TypeScript なサンプルが少ない
• Vue と Vuex の間での型の連携の弱さ
• Vue にデフォルトで備わってないフィールドを TypeScript が解決させるのが面倒

Nuxt は SPA モードでデプロイしました。一応サーバーサイドレンダリングが動くような形で作ってはいるのですが、Cloud Functions でコールドスタートが起きたら嫌だなーと思って、検証する時間もなかったので避けた次第です(なので未検証です)。

SSR 対応すると、SSR 未対応なコンポーネントを import するとエラーが起きることがあるので、開発からデプロイまで SPA モードでやると割り切ってもよかったと思います(参考1、参考2)。

UI は、Buefy を使いました。プロジェクトがシンプルで複雑なコンポーネントが不要であること、なるべく軽量なページにしたかったのが選定理由です。

プロジェクトのタイムライン

• 10/14：新郎から「こういうのやりたいんだよねー」と共有を受ける
• 10/21：Firebase のプロジェクトを作り、技術検証を始める
• 11/3：ご祝儀ドメインを取得
• 11/5：会場リハーサル
• 11/10：完成
• 11/11：本番

11/10 に締切がやばいことに気づいた図

そして当日...

当日は 100 人以上？の参加者がいたそうですが、障害もなく無事に動き、サーバーレス納品ができました。生きた心地がしなかったです。

結婚式、リアルタイムにコメントと写真共有できるやつ作ったの動いて良かった〜〜〜バイブス〜〜〜 pic.twitter.com/duHRzT1WDA

— やみつきー(小笠原みつき)＠ 76.2kg (@YAMITZKY) 2018年11月11日

ただ、端末依存のエラーは起きていてもおかしくないので、そのあたりは Sentry とか使ってトラッキングすればよかったなーと思っています。

また、イベントに関係ない写真の対策として、Firebase Authentication を使って投稿削除権限をつけたり、ML Kit で写真の解析をしたり、、、とかもできたら良かったなーと思います。

Firebase、本当に便利ですね。

かかった費用

約７円！！！！！！！！！！！！

まとめ＆今後の展望

このシステムは他のイベントにも簡単に転用できるように作っているので、リアルタイムコミュニケーションでイベントにグルーヴ感をもたらしたい方は Twitter などでお声がけいただければと思います*4。

また、デザイナーの @aixcheck や、新郎新婦を初めとする多くの方々にご協力をいただきました、ありがとうございます！

*1:一部加工済み

*2:なお、結婚式に参列するにあたってリアルマネーのご祝儀も渡しています。笑

*3:リアルタイムなフォトシェアサービスのような形で、サンプルプロジェクトを作るかもしれません

*4:協力いただいた方々にビールをおごれる程度にはしたいです

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

背景

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

用語

• SPA: Single Page Application. 単一のページ (index.html) で構成されるウェブアプリケーション
• SSR: Server-Side Rendering. SPA を事前に HTML として描画するやつ
• JAMstack: ウェブアプリケーション配信の構成で、JAM は JavaScript＋API＋Markup の略
• Vue.js: UI を作るための JavaScript のフレームワーク
• Nuxt.js: Vue をベースにしたフレームワークみたいなもので、SPA、SSR 、JAMstack にも対応している

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

サンプルリポジトリ

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

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

前提

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

• 「SPA と API」という構成にする
• フロントエンドは Nuxt などのレールに乗せる
• (ほぼ)同じオリジンとして扱う
  • localhost:8000 と localhost:3000 とかが出てくるとややこしい件

そもそもフロントエンドは独立したコードベース (≒ 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 の認証はだいたい３パターンぐらいあって、

• セッションを使った認証 (例1、例2)
• JWTなどのトークンでの認証 (例)
• @nuxtjs/auth プラグイン ※使ったことないけど楽っぽい予感

セッションや 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。

なぜ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 で通信するとき、公式の 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 はする必要がなくて、適当なファイル名でコピペすれば良い。

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ファイルで作られていたりする、すごい。