
## はじめに

最近、ゆったりとコーヒーを淹れる時間が好きになりました。これは私としては大きな転換点で、元々はコーヒーを淹れるのが面倒で全自動コーヒーマシンを買って使っていたこともありました。それすら面倒になり、一時期は全くコーヒーを飲んでいませんでした。しかし、今はコーヒーを飲むためのプロセスとして淹れているというよりも、コーヒーを淹れる時間そのものが楽しみになりつつあります。

![ペーパードリップの例](/assets/posts/2022/03/coffee-paper-drip/paperdrip.png)

そもそも、ペーパードリップとは何かをおさらいします。ペーパードリップとは、まずドリッパーと呼ばれる底に穴の空いた容器に紙のフィルターをセットし、そのフィルターにコーヒー粉を入れ、次に何度かに分けてお湯を注ぐことでコーヒーを抽出する手法です。

以前にペーパードリップを試した時は、何もかもうまくいかず時間ばかりがかかってイライラしてしまい、諦めてしまいました。何をどうすればいいかググりながら時間をかけて頑張っても、変な酸味や雑味付きの黒いお湯が出てくるだけでした。

しかし、ある時ふと思い立って、まず十分な機能を持った道具を一式揃えた上で、後述する 4:6 メソッドと呼ばれる手法をベースに計測と改善を行うようにした結果、工程を楽しみながら美味しいコーヒーが飲めるようになりました。

この記事では、ペーパードリップがうまくできずに悩みを抱える方や、ペーパードリップを試してみたい方に向けて、私が個人的におすすめしたい道具とペーパードリップの計測・改善方法を紹介します。

## 想定する読者

以下のような読者を想定しています。

- コーヒーを自分で淹れてみたい
- ペーパードリップを試してみたい
- ペーパードリップに苦手意識がある

## ペーパードリップのおさらい

まず、ペーパードリップの方法と必要な道具をおさらいしましょう。

[UCC 公式サイト](https://www.ucc.co.jp/enjoy/brew/drip.html) にてより丁寧に解説されているため、詳しく知りたい方はそちらをご覧下さい。

<Ogp src="https://www.ucc.co.jp/leqtmq00000000ex-img/og_ucc_official.png" title='コーヒーを淹れる | おいしいコーヒーの淹れ方 | 知る・楽しむ' href='https://www.ucc.co.jp/enjoy/brew/drip.html' />

<iframe width="560" height="315" src="https://www.youtube.com/embed/lNJJIiA1RwA" title="YouTube video player" frameBorder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" style={{maxWidth: '100%', width: '100%'}}allowFullScreen></iframe>

### 方法

![必須の道具たち](/assets/posts/2022/03/coffee-paper-drip/filter.png)

ペーパードリップをするにあたって、以下の道具が必須です。

- コーヒー粉
- ドリッパー
- ペーパーフィルター
- ドリップポット

これらを使ったペーパードリップの方法は次の通りです。

1. 準備  
  ドリッパーにペーパーフィルターをセットし、そこにコーヒー粉を入れます
1. 蒸らし  
  ドリップポットでコーヒー粉にお湯を注ぎ、コーヒー粉全体にお湯を行き渡らせます
1. 抽出  
  お湯を複数回に分けて注ぐことで、コーヒーを抽出することができます

### 道具

既に述べたペーパードリップに必須の道具に加え、以下の道具があると良いでしょう。


![あると嬉しい道具たち](/assets/posts/2022/03/coffee-paper-drip/mill.png)

#### あると便利

以下の道具があると便利です。

- ミル  
  コーヒー豆を挽いて粉にします  
  粉にせずに豆のまま保存した方が味が落ちにくいです
- サーバー  
  抽出したコーヒーを受ける容器です  
  一度にたくさんコーヒーを作る時に便利です

#### 計測と改善のために

そして、計測と改善を行いたい場合、以下の道具が必要です。

- 電子はかり  
  ドリッパーに注いだお湯の量や豆の重さを計測します
- ストップウォッチ  
  お湯を注いでから経過した時間を計測します
- 温度計  
  お湯の温度を計測します

## お湯の注ぎ方を学ぶ

### 悩み

ペーパードリップにおいて、私が最初に戸惑ったのはお湯の注ぎ方でした。どのぐらいの温度のお湯を、どのぐらいの量で、どのぐらいの時間間隔で注げば良いのか非常に悩みました。

これについては、あらゆるブログや書籍や動画において各々の見解が語られています。しかし、それぞれ食い違う意見も少なくないため、これらの断片的な情報を初心者が理解して体系化して実践することは難しいと感じました。

ただ、多くの情報源で共通して述べられていることは以下の通りでした。

- ドリップの工程では最初に酸味が抽出され、次に苦味、最後に渋味が抽出される
- 浅煎りの豆は酸味が、深煎りの豆は苦味・コク・甘みが強い
- お湯の温度が高ければ高いほど苦味や雑味が抽出されやすい

しかし、これだけでは「じゃあ実際にどう注げばいいんだろう」という疑問が解消されません。

### 4:6 メソッド

そこで、私は「初心者でも安定して淹れることができる方法」として下記ブログなどで紹介されている **4:6 メソッド** を試すことにしました。4:6 メソッドはオールラウンダーな抽出法で、固定されているパラメータと好みによって変動させるパラメータがはっきりと分かれているため、味の再現性を保ちながらも自分の好みにカスタマイズすることがとても容易です。

<Ogp src="https://every-coffee.com/wp-content/uploads/2020/10/46method-gram.jpg" title='【神か】世界一の4：6メソッド！粕谷哲さんのドリップコーヒーの淹れ方 | every coffee' href='https://every-coffee.com/article/world_champion_coffee_drip.html' />

ハリオ公式の下記動画がとても分かりやすいので、下記も合わせてご覧ください。

<iframe width="560" height="315" src="https://www.youtube.com/embed/8o7huqzruTE" title="YouTube video player" frameBorder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" style={{maxWidth: '100%', width: '100%'}} allowFullScreen></iframe>

4:6 メソッドでは、粗挽きのコーヒー粉の 3 倍の重量のお湯を 5 回に渡って注ぎます。例えば、20g のコーヒー粉を使って淹れる場合、60g のお湯を 5 回に分けて淹れていきます。

1. 60ml を注ぐ
1. 開始から 45 秒後に 60ml を注ぐ
1. 開始から 1 分 30 秒後に 60ml を注ぐ
1. 開始から 2 分 15 秒後に 60ml を注ぐ
1. 開始から 2 分 45 秒後に 60ml を注ぐ
1. 開始から 3 分 30 秒後にドリッパーを外す

そして、注ぐお湯のうち、前半の 40% の湯量では甘さと酸味のバランスを調整し、後半の 60% の湯量で濃度を調整します。
この前半と後半の 4:6 の割合からこの手法は「4:6 メソッド」と命名されています。前半・後半それぞれにおいてどのように調整を行えばよいのか見ていきます。

#### 前半 (甘さと酸味のバランスの調整)

<img alt='前半は一投目と二投目の比率によって調節する' src='/assets/posts/2022/03/coffee-paper-drip/first.png' style={{width:'404.5px', margin: 'auto', maxWidth: '100%'}} />

まず、前半の二投について考えます。先程「ドリップの工程では最初に酸味が抽出され、次に苦味、最後に渋味が抽出される」と述べた通り、一投目を多く注げば酸味が、二投目を多く注げば甘みが増します。例えば、一投目 80 ml、二投目 40 ml とするとかなり酸味が強くなります。

#### 後半 (濃さの調整)

<img alt='後半は回数によって調節する' src='/assets/posts/2022/03/coffee-paper-drip/second.png' style={{width:'404.5px', margin: 'auto', maxWidth: '100%'}} />

次に、後半の三投について考えます。この工程に突入するタイミングでは酸味の抽出は既に終わっており、どれぐらい濃くするかをコントロールする工程になります。濃いめに淹れたい場合は一投分の量を減らしつつ回数を増やし、薄めに淹れたい場合は一投分の量を増やしつつ回数を減らします。例えば、30 秒間隔で 45 ml ずつ 4 回投下すれば濃くなりますし、1 分間隔で 90 ml ずつ 2 回投下すれば薄くなります。

### 4:6 メソッド抽出モデル作成器

しかし、これらを自分で計算するのは面倒ですよね。そこで、Arakun さんが作成された「4:6メソッド抽出モデル作成器」が便利です。

<Ogp src="https://arikuicafe.com/wp-content/uploads/2021/02/logo3.png" title='4:6メソッド抽出モデル作成器 | Arikui Cafe' href='https://arikuicafe.com/46method-modelgenerator/' />

「4:6メソッド抽出モデル作成器」は、コーヒー豆の量、お湯の量、好みの味、好みの濃さを入力するだけで、よしなに抽出モデルを作成してくれます。例えば、「20g・300ml・甘め・濃いめ」の場合は以下のような出力結果になります。

![4:6メソッド抽出モデル作成器「20g・300ml・甘め・濃いめ」の場合](/assets/posts/2022/03/coffee-paper-drip/generator.png)

### 4:6 メソッドのまとめ

初心者である私は、最初は 4:6 メソッドにそのまま従いながら、少しずつパラメータを変動させて自分好みにカスタマイズすることで、自分が好きなコーヒーの淹れ方を少し掴むことができました。

次章では、それらの計測と改善を行うために便利な道具を紹介します。

## 道具を揃える

### 計測と改善のために

読者の皆様もご存知の通り、あらゆる改善は計測から始まります。適切に現状を理解しなければ、改善を行うことができません。そして、計測を行うためには、迅速かつ正確に情報を得られる必要があります。

#### タニタ デジタル温度計 TT-508N

<Ogp src="https://m.media-amazon.com/images/I/51WVZTZ7tRL._AC_SY879_.jpg" title='デジタル温度計 料理用スティック温度計 TT-508N (￥2,587)' href='https://www.amazon.co.jp/gp/product/B07CZ61DDS' />

再現性を高めるためには、お湯の温度がぶれない方が望ましいでしょう。
また、温度を調整することで自分の好みに向けて改善することも可能です。

そこで、温度計はある程度精度が高く、かつ素早く反応するものを使うと良さそうです。
タニタのデジタル温度計 TT-508N は、0.5 秒毎に更新されるし、だいたいお湯に突っ込んで 15 秒ぐらいで温度を表示してくれます。
ただし、50-250 度に対応しているものの、プラスチック部分は耐熱ではないため、あまり高温に使うことはおすすめしません。


#### タニタ クッキングスケール KJ-212

<Ogp src="https://m.media-amazon.com/images/I/512-HSHK0sL._AC_SX679_.jpg" title='タニタ クッキングスケール KJ-212 (￥2,443)' href='https://www.amazon.co.jp/-/en/dp/B072TFKYP4' />

どのぐらいお湯を入れたのかを測るために、はかりの上にサーバを置いて淹れると便利です。
私が使っているタニタのクッキングスケール KJ-212 は、コーヒーをこぼしてもカバーが洗えるし、コーヒーを淹れるために必要な最低限の機能のみを有するシンプルで、0.1g 単位で測れるので投入したコーヒー粉の量も分かるのでおすすめです。

### 再現度を高めるために

#### ドリップポット: タカヒロ コーヒードリップポット

<Ogp src="https://m.media-amazon.com/images/I/51QgQJX7oVL._AC_SX679_.jpg" title='タカヒロ コーヒードリップポット 0.5L 18-8ステンレス (￥8,980)' href='https://www.amazon.co.jp/gp/product/B009DYPDHY' />

最初はお茶を淹れる用の適当なポットを使ったり、お湯を沸かすために使った電気ケトルからそのまま淹れたりしていましたが、勢いあまってお湯がバッと入って全部が終わっちゃうやつを何度かやりました。うまく均等に注ぎたくても狙った方向に行かず、出来にムラができることもしばしばありました。

タカヒロのコーヒードリップポットは、とてもコントロールしやすいだけでなく、蓋の口が広いので、手を入れて洗浄することができて便利です。お値段はそこそこしますが、見た目も可愛くて気分が高まるのでおすすめです。

また、地味に便利なのが、蓋が落ちにくい設計になっていることです。ポットを傾けたら蓋が落ちてイライラなんてことはしょっちゅうあるかと思いますが、どんなに傾けても落ちないので本当に嬉しいです。

ステンレス製なのでサビに強く直火にかけられるのもメリットです。私はティファールで沸かしたお湯をこれに移し替えて使っていますが...。

#### コーヒーミル: タイムモア C2

良いミルの条件の一つとして、挽いた粉の大きさが均一で、微粉が少ないことが挙げられます。挽いた粉の大きさが均一でないと、抽出にムラが出てしまい、味の再現度が大きく落ちてしまいます。特に、微粉は抽出がすぐに終わり、後は出がらしを出すだけです。

ところでミルは主にハンドミルと電動ミルの二種類がありますが、電動ミルは 2 万円ぐらい出さないと満足できる精度で挽いてくれません。一方で、ハンドミルは 7000 円程度でそれなりに満足できる精度で挽いてくれるものがあります。

また、「電動ミルの方が自動だから楽」と思われがちですが、電動ミルの清掃やメンテナンスのコストは無視できるものではないし、場所もかなり取ってしまうので自宅で気軽に淹れるにはやや厳しいものがあります。

<Ogp src="https://cdn.shopify.com/s/files/1/0480/0115/5238/products/C2_37bc4a19-bcab-4cb7-bd60-3515722173f3_2048x2048.png?v=1629453275" title='TIMEMOREタイムモア C2 (￥7,200)' href='https://timemore.jp/products/timemore-c2-%E6%B5%8B%E8%AF' />

さて、先程「ハンドミルは 7000 円程度でそれなりに満足できる精度で挽いてくれるものがある」と書きましたが、それがタイムモア C2 です。タイムモア C2 は挽目が均一で、挽き心地が大変軽いです。

以前に使っていたカリタの 3000 円ぐらいのミル KH-9N では 20g の豆を挽くのに 5 分ぐらい掛かっていましたが、タイムモア C2 では 30 秒ぐらいで終わります。正直、最初はミルに 7000 円を出すことにかなり戸惑いましたが、毎日 5 分も掛けて豆を挽いてヘトヘトにならずに済みますし、本当にいい買い物でした。

また、タイムモア C2 の挽目の均一さは多くのブログなどでも述べられています。以下のブログではメリタの電動ミルと挽目を比較しています。

<Ogp src="https://life-effect.net/wp-content/uploads/2021/07/タイムモア-栗子-C2レビューこのコーヒーミルがほぼ最強な理由＼´ω｀-890x500.jpg" title='タイムモア 栗子 C2 レビューこのコーヒーミルがほぼ最強な理由＼(´ω｀) | LIFE effect Blog' href='https://life-effect.net/timemore-c2-review/%AF' />

### 自分の好みのために

ドリッパーによって味の特徴は大きく変わります。自分の好みにあったドリッパーを使うと嬉しいです。

![コーノ MDN-21 & ハリオ V60](/assets/posts/2022/03/coffee-paper-drip/konohario.png)

#### ドリッパー① ハリオ V60 透過ドリッパー

<Ogp src="https://m.media-amazon.com/images/I/61CzzA75f0L._AC_SX679_.jpg" title='HARIO (ハリオ) V60 透過 コーヒードリッパー 02 クリア コーヒードリップ 1~4杯用 VD-02T (￥356)' href='https://www.amazon.co.jp/-/dp/B001RBTSMM' />


4:6 メソッドを行う上でよく勧められるのが V60 です。V60 の特徴として、螺旋状のリブ (突起) がフィルターとの密着を防ぎ、珈琲粉を膨らみやすく、空気を抜けやすくしています。これにより、素早く抽出が行われます。また、注ぎ方によって味を調整することができます。素早く注げばすっきりした味に、ゆっくり注げば深みのある味になります (雑味も出やすくなりますが)。

#### ドリッパー② コーノ 名門 2 人用フィルター MDN-21

<Ogp src="https://m.media-amazon.com/images/I/51j7yjjAujL._AC_SX679_.jpg" title='コーノ 名門 2人用 フィルター MDN-21 (￥935)' href='https://www.amazon.co.jp/-/dp/B01HPW2CBK' />


コーノの名門フィルターは喫茶店でもよく使われているドリッパーで、リブ (突起) が下部のみにあるのが特徴です。リブが短いため、一度しっかりとお湯をドリッパー内に溜めてから抽出されることから、ネルドリップに近い重量のある味わいを再現してくれます。私はわりとどっしりとしたコーヒーが好きであることが分かってきたので、最近はコーノの名門フィルターにチャレンジしています。

以下のブログにて、ハリオ V60 とコーノ名門フィルターの比較がなされているので、ご紹介します。

<Ogp src="https://takaneman.co/wp-content/uploads/2017/06/DSCF1312.jpg" title='どのドリッパーがいいのか？Part２（ハリオ式とコーノ式の違い） | Takane Man Coffee' href='https://takaneman.co/%E3%81%A9%E3%81%AE%E3%83%89%E3%83%AA%E3%83%83%E3%83%91%E3%83%BC%E3%81%8C%E3%81%84%E3%81%84%E3%81%AE%E3%81%8B%EF%BC%9Fpart%EF%BC%92/' />

# まとめ

ベースとなるお湯の注ぎ方を一つ持った上で、それらをうまく自分好みにカスタムするために、ストレスなく高い再現性でコーヒーを淹れられる道具を揃えるのがおすすめです。もし読んでくれる方がいれば今後も継続してコーヒーの話を書くかもしれないので、感想をツイートしてくれたら嬉しいです。


ペーパードリップの初心者が安定してコーヒーを淹れるための方法と道具

## はじめに

BigQuery を利用する上で、うっかり高額なクエリを投げてしまったことはありませんか?また、「BigQuery を利用したいけれど課金額が分からないと破産しそうで怖い」という方もいるのではないかと思います。

- 例: [BigQueryで150万円溶かした人の顔 - Qiita](https://qiita.com/itkr/items/745d54c781badc148bb9)

そこで、BigQuery のエクスプローラ画面で、入力したクエリの課金額を実行前にその場で表示してくれる UserScript を作成しました。

![BigQuery の課金額が表示されている様子](//images.ctfassets.net/2fi9g7v28whp/2mC5RGS1oJpj46fB5U6VE2/1ead3c8c45d316db5df6f57ca2660a74/____________________________2022-02-05_16.37.40.png)

本記事では、まず前提として Web サービス開発者にとっての BigQuery の有用性を述べた上で、BigQuery の課金体系をおさらいします。その上で、本記事で解決したい課題である「BigQuery のクエリへの課金額を実行前にその場で知りたい」について述べ、その解決策である UserScript について解説します。

## 前提

まず、前提として、BigQuery がどのようなソリューションで、どのように Web サービス開発者に利用されるか、そして BigQuery を利用する上で注意するべき事項として BigQuery の課金体系を述べます。

### Web サービス開発者と BigQuery

__BigQuery__ は Google Cloud で提供されているフルマネージドなデータウェアハウスです。一般には BigQuery は「データサイエンティストがビッグデータを高速に解析するためのソリューション」として紹介されることが多いですが、BigQuery は Web サービス開発者にとっても非常に有用なソリューションです。

例えば、不具合の影響範囲を調査したり、負荷対策のために各エンドポイントへのアクセス傾向を調査したりするために、膨大なアプリケーションログを解析しなければならない時があるかと思います。しかし、ローカル環境に TB 単位のログを持ってくるのは大変ですし、Google Cloud Logging のログエクスプローラは膨大なログ解析に対しては速度の面で不向きです。

そんな時に、BigQuery は非常に便利です。公式ドキュメントに以下の記載があるように、BigQuery では膨大なアプリケーションログの分析も素早く済ませることができます。

> BigQuery のスケーラブルな分散型分析エンジンを使用すると、数テラバイト、数ペタバイトのデータに対し、数秒もしくは数分でクエリを完了できます。
> - https://cloud.google.com/bigquery/docs/introduction

### BigQuery の課金体系

一方で、他のクラウドサービスもそうであるように、BigQuery を利用するためには必ず課金体系を理解する必要があります。

[公式ドキュメント](https://cloud.google.com/bigquery/pricing?hl=ja) によれば、BigQuery の課金体系は以下に分類できます。

- ストレージ料金
  ログを保存するために掛かる費用
- 分析料金
  保存したログを分析するために掛かる費用

特に、BigQuery をオンデマンドに利用する場合、分析料金は米国リージョンで $5.00/TB、東京リージョンでは $6.00/TB (2022 年 2 月現在) となっています。また、BigQuery では [カラム型ストレージ](https://cloud.google.com/blog/ja/products/data-analytics/bigquery-explained-storage-overview) が採用されているため、スキャンした列のデータの合計容量に応じた課金が行われます。

特に注意するべきことは、「スキャンした列のデータの合計容量に応じた課金が行われる」ということです。たとえば、うかつに `SELECT * FROM ...` をしてしまうと、すべての列をスキャンしてしまい、それだけ課金額が増えてしまいます。さらに、`LIMIT 1000` や `WHERE ...` のように読み出す行数を制限したとしても、指定した列へのスキャンは必ず行われるため、課金額は変わりません。つまり、必要な列だけを指定してクエリを構築することが重要です。

また、[カスタム割り当て機能](https://cloud.google.com/bigquery/docs/custom-quotas) を利用することで、1 日に処理されるクエリデータの量を制限し、想定を超えた課金が発生することを防ぐことができます。

BigQuery のコストを最適化するベストプラクティスとしてより詳しい情報を知りたい場合、[こちら](https://cloud.google.com/blog/ja/products/data-analytics/cost-optimization-best-practices-for-bigquery) の公式ブログ記事を読むことをおすすめします。

## 課題

私が抱えていた課題は、「これから投げる BigQuery のクエリに対する課金額の概算をパッと知りたい」です。BigQuery のエクスプローラは、以下の図のように処理されるデータサイズを表示してくれますが、私はその場で課金額が自動で計算されて表示されて欲しいと感じていました。

![bq_billed_bytes](//images.ctfassets.net/2fi9g7v28whp/2MnMV1zrSeV4ojue3jbWkA/d6dfab2db3b35219448d71389bf478e0/____________________________2022-02-05_16.48.29.png)

## 解決策

### 要件

そこで、私は以下のような機能を実現したいと考えました。

1. そのクエリで処理されるバイト数を取得する
2. バイト数から課金額を計算し表示する

### UserScript にした理由

ブラウザで表示しているページを手軽に書き換える方法として、たとえば以下があります。
今回は、「手軽に複数のブラウザに向けて公開したい」「ユーザが一度導入したら意識せずに機能が働いて欲しい」「ユーザのリテラシは高いと考えて良い」という要件のため、UserScript として開発しました。

- 各ブラウザの拡張機能
    - ユーザが簡単に機能を導入できる
    - 開発者は提供したい各ブラウザの拡張機能の仕様に合わせる必要がある
- UserScript
    - 開発者は簡単に複数のブラウザに向けて機能を公開できる
- ブックマークレット
    - ユーザが能動的にアクションしないと実行されない

### 処理されるバイト数の取得

また、処理されるバイト数を取得する方法としてすぐ思いつく方法は「DOM からテキストを取得してパースする」があるかと思います。BigQuery ではクエリを書き換えるたびに処理されるバイト数を表示してくれるので、この DOM を MutationObserver で監視すれば取得できるでしょう。しかし、`10 MB` のように整形されたテキストよりも生のバイト数の方が扱いやすいため、この方法は採用しませんでした。

代わりに、以下の方法で実現しました。

まず、`XMLHttpRequest.prototype.send` をオーバーライドして XHR による通信を監視します。

```javascript
(function() {
    const globalSend = XMLHttpRequest.prototype.send;
    XMLHttpRequest.prototype.send = function(){
        this.addEventListener("readystatechange", function() {
            // XHR による通信のレスポンスが取得できる
            console.log(this.responseText)
        }, false)
        globalSend.apply(this, arguments)
    }
}
```

次に、レスポンステキストに `totalBytesProcessed` が含まれている場合は、レスポンステキストを JSON 形式としてパースし、処理されるバイト数を取得します。

```javascript
if (this.responseText.includes("totalBytesProcessed")) {
    const totalBytesProcessed = JSON.parse(this.responseText)[0]?.data?.response?.totalBytesProcessed
}
```

この方法はあまり行儀の良いやり方ではないため、場合によっては利用者を不安にさせるかもしれませんが、今回の UserScript は全体で 50 行に満たない非常に小規模なスクリプトであるため、このスクリプトに危険性が無いことをご理解頂いた上で利用していただけると考えました。

### スクリプト

以下に該当のスクリプトを公開しています。

今回のスクリプトでは、米国リージョンを基準にした料金を表示するため、他リージョンでの金額を表示したい方はよしなにスクリプトを書き換えていただければと思います。

[iwasa-kosui/how-you-will-be-billed-with-big-query.user.js - GitHub Gist](https://gist.github.com/iwasa-kosui/7fede688956e18e8ed7b57d9ade53b65)

## おわりに

課金額に気をつけながら、快適な BigQuery ライフを送りましょう。

## 免責事項

私は当ページに掲載した情報について可能な限り安全かつ正確であるように努めておりますが、安全性または正確性などについて責任を負うものでは有りません。
当ページに掲載された情報によって生じたあらゆる損害等について、理由の如何に関わらず、私は一切責任を負いません。

BigQuery を利用する上で、うっかり高額なクエリを投げてしまったことはありませんか? BigQuery のエクスプローラ画面で、入力したクエリの課金額を実行前にその場で表示してくれる UserScript を作成しました

BigQuery の課金額で泣かないための UserScript

## 概要

私のこのブログの既存の問題点を述べた上で、それに対してどのように解決を図ったか述べます。

以下では御託をつらつらと並べておりますが、MDX の導入や Contentful との連携はさておき、Gatsby からの移行については私が Next.js をやってみたかったという気持ちが移行理由の多くを占めています。どうかその辺を心に留めていただいた上でお読み頂ければ幸いです。

## 抱えていた課題

### Gatsby に関する私の不勉強

Gatsby と Next.js はいずれも　React をベースとした静的サイトジェネレータとして著名であり、それぞれがお互いにない長所を有しています。

- [Gatsby 公式による比較](https://www.gatsbyjs.com/features/jamstack/gatsby-vs-nextjs)
- [Next.js 公式による比較と移行方法](https://nextjs.org/docs/migrating/from-gatsby)

Gatsby は強力なプラグインシステムを有する一方で、このプラグインシステムに適切に乗っかるためにはこれに対する一定の理解が求められるように思います。フロントエンドに関する仕事や活動を私はほとんど行っていないため、私には個人ブログをいじる時にしか Gatsby に触れる機会がありません。そのため、気軽な機能追加をサクッと行おうとしても、恥ずかしながら「一歩進んだと思えば進んでいなかった」を繰り返すことになり、中々重い腰を上げる気が起きませんでした。

### TypeScript を導入していない

従来の私の個人ブログには TypeScript が導入できていなかったため、これがさらにリファクタする気力を削ぐ要因になっていました。

### Remark Custom Blocks による拡張の限界

Gatsby でマークダウンファイルをレンダリングする際には Remark とそのプラグイン gatsby-transformer-remark がよく用いられると思いますが、記事内に独自のカスタム機能を利用したくなることもしばしばあるかと思います。そこでよく利用されるプラグインとして gatsby-remark-custom-blocks があります。gatsby-remark-custom-blocks は remark-custom-blocks をベースとしていて、以下のような記法で指定したクラスを持つ div 要素を生成することができます。

```markdown
[[foobar | タイトル]]
| おはよう  
| こんにちは  
| こんばんは
```

```html
<div class="custom-block foobar">
  <div class="custom-block-heading">タイトル</div>
  <div class="custom-block-body"><p>おはよう<br>こんにちは<br>こんばんは</p></div>
</div>
```

しかし、この要素内にコードブロックを埋め込もうとすると以下のように `|` を続ける必要があり、さらにこれをネストさせるとそれなりに可読性が下がるという問題がありました。入力に取れる要素もタイトルと本文のみであり、実装できる機能が制限されるケースもあります。

### 投稿コストが高い

これまで私は CMS を利用しておらず、記事に関する元ファイルはすべて GitHub 上にホストし、記事の執筆はすべて VSCode で行っていました。しかし、画像のアップロードや下書きの管理が面倒で、投稿までのハードルがそれなりに高い状況が続いていました。

## 解決策

### Next.js への移行

どうせリファクタするならこのシルバーウィークにコンテンツ以外をすべて新しく作り直してしまおうと考えました。加えて、せっかくなら今まであまり利用したことがない Next.js を試してみようと思いました。Next.js は Automatic TypeScript configuration and compilation を謳っていて、チュートリアルやドキュメントでも TypeScript プロジェクトに向けた解説が数多く記載されているため、まずは試してみることにしました。

Gatsby からの移行にあたっては、[Next.js 公式の移行ガイド](https://nextjs.org/docs/migrating/from-gatsby) を参考にしました。

ただ、結局はフレームワークを使う以上、その中身を理解している必要があることには変わりなく、Next.js の内部構造に対する理解をこれから深めていく必要があると思いました。

### MDX への移行

MDX は Markdown の拡張であり、自分で定義した React コンポーネントを MDX ファイルの中で利用することができます。

[Markdown を拡張する MDX はドキュメント作成の新たな可能性？](https://zenn.dev/spring_raining/articles/3eb62ff93df1eb)

これにより、記事内により複雑な機能を持つコンテンツを追加することができるようになりました。

以下を参考に移行しました。

- [Markdown/MDX with Next.js
](https://nextjs.org/blog/markdown)
  MDX ファイルからページを生成する方法
- [Syntax highlighting | MDX](https://mdxjs.com/guides/syntax-highlighting/)
  MDX ファイル上のコードのシンタックスハイライトの実現方法

Remark から MDX への移行では、Markdown ファイルに記載された HTML タグを JSX として適切な形に変換する必要があります。特に class 属性や style 属性には注意が必要です。

### Contentful との連携

ヘッドレス CMS を採用することで、気軽にサクッと書きたい記事はヘッドレス CMS で、プレビューを行いながらしっかり書きたい記事は手元で書けるようにしました。ちなみに、これまでの記事に関するファイルは引き続き GitHub 上に置いています。

特に Contentful は無料ユーザから有料ユーザへの移行もシームレスに行える上に、エクスポートツールなども用意されていて安心して使えそうだと思いました。また、Gatsby や Next.js での Contentful の利用方法は広く共有されているため、導入もスムーズに行うことができました。

[Contentful 公式のページ](https://www.contentful.com/developers/docs/compose/building-a-website-with-compose/)にて Contentful の Next.js への導入方法が記載されているため、チェックしてみて下さい。

## その他

- react-helmet から next/head へ移行した
- RSS フィードの生成は [catnose99 さんの記事](https://zenn.dev/catnose99/articles/c7754ba6e4adac) を参考にした
  - ただしすべて SSG したかったので `getStaticProps` の時に生成した
  - 今書いていて気が付いたが `getStaticPaths` でやるべきだったのでは

## おわりに

コンテンツが少なかったことや個人ブログということもあってやや横暴な技術選定を行った背景もあり、基本的な機能の移行に掛かった時間は合計で 7 時間程度とかなり短く済みました。

ただし、目次の生成や Google Analytics の導入が完了していないため、それらを行う予定です。この辺は Gatsby ではプラグインが全て行ってくれるので、やはりその辺は Gatsby の強みだなと思いました。

このブログの既存の問題点とそれに対するアプローチ

このブログを Gatsby + Remark から Next.js + MDX + Contentful へ移行しました


## はじめに

様々なやんごとなき事情によって、手元でささっと `source .env` もしくは `env $(cat .env) foobar` したくなる時はありませんか。  
私はあります。

しかし、以下の記事にて指摘されている通り、 `.env` ファイルのシンタックスは、Bash や Zsh などの Bourne Shell 互換のシェルにおける変数の宣言のシンタックスとは異なります。

[安直に .env ファイルを export しないで欲しい](https://zenn.dev/red_fat_daruma/articles/7f0ebe9c4d5659)

実際、上記の記事で挙げられているものを `source .env` にて読み込もうとすると以下のような結果となります。

```
$ cat .env
including_space=hello world
push_to_background=hello &
pipe_to=hello | world
redirect_to=hello > world
end_statement=hello; world
comment_tailing=hello # world

$ source .env
.env:1: command not found: world
.env:2: parse error near `&'
```

しかし、それでもなお様々なやんごとなき事情によって手元でささっと .env の中身を環境変数として読み込みたい時がきっとあるかもしれません。

## 解決策

私は https://github.com/joho/godotenv を利用することにしました。
joho/godotenv は Ruby dotenv プロジェクトの移植実装であり、現在も継続してメンテナンスされている様子が伺えます。
試してみましょう。

```zsh
$ go get -u github.com/joho/godotenv/cmd/godotenv

$ godotenv -f .env zsh

$ env | grep hello
comment_tailing=hello
including_space=hello world
push_to_background=hello &
pipe_to=hello | world
redirect_to=hello > world
end_statement=hello; world
```

無事に読み込むことができました。良かったね！

## おまけ

実は oh-my-zsh の dotenv plugin でも `source` で `.env` file を読み込んでいるため、上記のファイルを正しく読み込むことができません。
コントリビューションチャンスかなと思ったのですが、この次にご紹介する gist を見て諦めました。

https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/dotenv/dotenv.plugin.zsh#L47

`.env` ファイルをダイレクトに bash へ読み込ませることについて、以下の gist に先人たちの苦労が記されています。
以下の議論をお読みいただければ、いかにこれが厳しい道程であるかが伝わるかと思われます。
多分 zsh でも同じように辛いと思います。

https://gist.github.com/judy2k/7656bfe3b322d669ef75364a46327836



シェルの文法と .env ファイルの文法が違うことで生まれる問題とその暫定的解決

それでも .env を env したい

コンパイラの基礎知識をおさらいした上で、公式 Go コンパイラ gc のコードを個人的な面白いポイントと共に紹介します

Go コンパイラのコードを読んでみよう

ISUCON10 予選敗退の記録と反省


## はじめに
本記事では、二者間交渉において、交渉解として著名な、ナッシュ交渉解、カライ・スモルディンスキー解、均等解(カライ解)を紹介する。

## 注意書き
カライ・スモルディンスキー解および均等解は、二者間交渉の場合と、三者以上による交渉の場合で、満たす公理が異なる。本記事では、 **二者間交渉における** カライ・スモルディンスキー解、均等解について紹介する。

## 二者間交渉とは
二者間交渉とは、文字通り、二者間で行われる交渉である。
二者間交渉では、合意案候補の集合から、交渉によって合意案が一つ決定される。

例えば、 `太郎` と `花子` がどこで夕食を食べるか交渉する時、合意案候補集合 `サイゼリヤ` ・ `洋麺屋五右衛門` ・ `吉野家` から、交渉によって合意案として どれか一つを選択する。この時、`太郎`と`花子`はそれぞれ、自分自身の効用が最大になるように交渉を進める。

「効用」というのは、例えば、`太郎`から見て「`サイゼリヤ`は80点、`洋麺屋五右衛門`は60点、`吉野家`は90点」などの「合意案候補に対する満足度」である。また、「与えられた合意案候補に対して、ある交渉参加者から見た満足度を返す関数」は「効用関数」と呼ばれる。

## 交渉解とは
交渉解とは、二者間交渉において最も合理的な合意案を導出する方法・ルールを指す。
つまり、ある特定の交渉解に従って合意案を選択することで、合理的な合意案を決定することができる。

しかし、この3つの交渉解それぞれにおいて「合理的な合意案」の定義が異なる。
つまり、3つの交渉解において、どのような公理を満たすべきかがそれぞれ異なる。
それぞれの交渉解が、二者間交渉においていずれの公理を満たすかを、以下の表に示す。

|                               | 公理1 | 公理2 | 公理3 | 公理4 | 公理5 |
|-------------------------------|-------|------|------|------|-------|
|ナッシュ交渉解(1950)              | ○     | ○    | ○    | ○     | ×     |
|カライ・スモルディンスキー解(1975)  | ○    | ○    | ×     | ○    | ×(※1)    |
|均等解(1977)                    | ×(※2)    | ×    | ○    | ○     | ○    |

※1 カライ・スモルディンスキー解は、単調性は満たさないが、限定単調性を満たす。
※2 均等解は、パレート最適性は満たさないが、弱パレート最適性を満たす。

## ナッシュ交渉解が満たす公理1~4と満たさない公理5
### ナッシュ交渉解(Nash bargaining solution)とは
ナッシュ交渉解とは、各交渉参加者の効用の総乗を最大化する合意案候補を合意案とする、ナッシュが導出した交渉解である。
公理1~4を満たす唯一の交渉解である。

かみ砕いて説明すると、AとBが参加する二者間交渉において、AとBの獲得するスコアの積を最大化する合意案候補を合意案とすれば、公理1~公理4は必ず満たされる。また、公理1~4をすべて満たす交渉解はナッシュ交渉解の他に存在しない。

以下の図でいえば、原点と合意案候補を頂点に持ち、X軸とY軸を辺に持つ長方形の面積が最大になるような合意案候補が、合意案として選ばれる。
実際、合意案が成す長方形(赤色)の面積は、それ以外の合意案候補が成す長方形(緑色)の面積より大きい。

![](https://i.imgur.com/gAvE0g6.png)

コラム: 「ナッシュ均衡とは関係があるんですか？」という質問をいただくことがある。ナッシュ均衡とナッシュ交渉解は別々の概念ではある。しかし、「非協力ゲームを何かいい感じに協力ゲームへ近似すると、ナッシュ均衡とナッシュ交渉解は同一になる」ということをナッシュが証明している。サラっと書いたが、めちゃくちゃすごいことである。

<blockquote className="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">検索をすると「ナッシュ均衡」に関するtweetは山ほど引っかかるけど、やはり「ナッシュ交渉解」はほとんどない。協力ゲームの代表的な解概念となり、公理論的な特徴付けの走りとなったこちらも、実はノーベル賞級の業績。Google Scholarによると、引用件数はどちらも7000件台。</p>&mdash; 安田 洋祐 (@yagena) <a href="https://twitter.com/yagena/status/602653901662326784?ref_src=twsrc%5Etfw">2015年5月25日</a></blockquote>

<blockquote className="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">奇跡的な両論文を二十歳そこそこで書いてからわずか数年後に、具体的な交渉ゲームを通じて協力ゲームの「ナッシュ交渉解」を非協力ゲームの「ナッシュ均衡」として説明したーつまり、バラバラのアプローチであった両分野を繋いだー「ナッシュ・プログラム」も特筆すべき業績。やっぱりナッシュすげぇ…</p>&mdash; 安田 洋祐 (@yagena) <a href="https://twitter.com/yagena/status/602655708765691904?ref_src=twsrc%5Etfw">2015年5月25日</a></blockquote>

すごいことである。

詳しい解説は[金沢大学の半沢英一先生の講演資料](https://mathsoc.jp/publication/tushin/1104/hanzawa.pdf)の18章前後に記載されている。

### 公理1: パレート最適性   
その交渉解が導出する合意案がすべての交渉空間においてパレート最適である場合、その交渉解はパレート最適性を満たす。

かみ砕いて説明すると、「パレート最適性」とは、決定された合意案と比べて、「お互いが損をせずに、少なくとも一方がより得をする」合意案候補が存在しない性質を指す。

![](https://i.imgur.com/RT2JFS9.png)

### 公理2: 正アフィン変換からの独立性   
すべての交渉空間において、交渉空間に対して正アフィン変換を行っても合意案が変わらない場合、その交渉解は正アフィン変換からの独立性を満たす。

例えば、ナッシュ交渉解は公理2を満たすため、以下のように交渉空間に対してアフィン変換を行っても、ナッシュ交渉解は同一の合意案候補を合意案として選択する。

![](https://i.imgur.com/T5YhvVj.png)
![](https://i.imgur.com/Kbx7JjH.png)

### 公理3: 無関係な他の合意案候補の候補からの独立性   
すべての交渉空間において、交渉解によって決定された合意案以外の合意案候補を交渉空間から取り去っても、合意案が変わらない場合、その交渉解は無関係な他の合意案候補の候補からの独立性を満たす。

かみ砕いて説明すると、「無関係な他の合意案候補の候補からの独立性」とは、合意案じゃない合意案候補を交渉空間から消しても合意案が変わらない性質を指す。

![](https://i.imgur.com/ExXBLWZ.png)


### 公理4: 対称性   
すべての交渉空間において、交渉参加者を入れ替えても、ある交渉解が元の合意案に対して対象な合意案候補を合意案として選択する場合、その交渉解は対称性を満たす。

かみ砕いて説明すると、対称性を満たす交渉解は、交渉参加者のAさんとBさんの立場を入れ替えても、対称な合意案候補を合意案として選択する。

### 公理5: 単調性   
すべての交渉空間において、交渉空間に新しい合意案候補が加えられたことで合意案が変更されても、交渉参加者のいずれも損をしない場合、交渉解は単調性を満たす。

ナッシュ交渉解はこれを満たさない。
たとえば、以下の例では、新たに追加された合意案候補が新たに合意案として選択されるが、この場合はBの効用は減少してしまう。

![](https://i.imgur.com/qhs4m1Q.png)

## カライが目指した単調性の実現
交渉解が単調性を満たさない場合、後出しで追加された合意案候補のせいで、誰かが損をする場合が出てしまう。一般に、後出しで出された合意案候補が採用されて損をした人間が良い気持ちになるとは思えない。絶対に殴り合いになる。少なくとも、私の地元はそういう街だと思う。

カライは、ナッシュ交渉解が単調性を満たさないことを指摘し、1975年にカライ・スモルディンスキー解、1977年に均等解(カライ解)を提案した。

### カライ・スモルディンスキー解
カライ・スモルディンスキー解は、二者間交渉において、「公理3: 無関係な他の合意案候補の候補からの独立性」「公理5: 単調性」以外の3つの公理と、「限定単調性」を満たす交渉解[2]。個人効用÷最大効用の比率が交渉参加者間で最も均等になる合意案候補を合意案とする。限定単調性を満たす交渉解は、各参加者が交渉中に獲得できる最大の効用の組(理想点)が同一である場合にのみ単調性を満たす。

> [2] Kalai, Ehud, and Meir Smorodinsky. "Other Solutions to Nash's Bargaining Problem." Econometrica 43, no. 3 (1975): 513-18. doi:10.2307/1914280.

### 均等解(カライ解/Egalitarian solution)
均等解は、二者間交渉において、「公理1: パレート最適性」「公理2: 正アフィン変換からの独立性」以外の3つの公理と、「弱パレート最適性」を満たす交渉解[3]。最も得られる効用が低い交渉参加者の効用を最大化する合意案候補を合意案とする。一番損をする参加者ができるだけ損をしないようにしてくれるため、一人負けが発生しにくい平等主義的な解。

> [3] Kalai, Ehud. "Proportional Solutions to Bargaining Situations: Interpersonal Utility Comparisons." Econometrica 45, no. 7 (1977): 1623-630. doi:10.2307/1913954.

#### 弱パレート最適性とは
ある交渉解が選択した合意案から見て「参加者全員が同時により得をする合意案候補」が必ず存在しない場合、その交渉解は弱パレート最適性を満たす。

![](https://i.imgur.com/teV4aBb.png)

## ナッシュ交渉解と均等解の比較
* ナッシュ交渉解は当事者の効用の積を最大化する一方で、均等解は当事者の効用の最小値を最大化する。このことから、ナッシュ交渉解はより功利主義的であり、均等解はより平等主義的といえる。
* 交渉空間に新たな合意案候補が次々に追加されていくような状況では、単調性を満たさないナッシュ交渉解による合意案の選択は争いを招きかねない。
* 逆に、交渉空間が変更されない状況下では、単調性は意義を失う。そのため、パレート最適性を満たさない均等解は用いるべきではないといえる。

なお、より詳しい分析・比較は、本記事では扱わない。本記事の位置付けは、あくまでそれらへの足がかりとする。分配的正義(配分的正義ではない)の話とかも出てきてややこしいので...

ご不明な点・気になる点・誤っている点があれば[Twitter/@ebiebievidence](https://twitter.com/ebiebievidence)までご一報ください。

協力ゲームにおける交渉解として著名な、ナッシュ交渉解、カライ・スモルディンスキー解、均等解(カライ解)を紹介する

二者間交渉ゲームにおける交渉解の比較


# はじめに

この記事では[Web Speech API](https://developer.mozilla.org/ja/docs/Web/API/Web_Speech_API)による音声認識・音声合成機能について、ブラウザ対応状況・利用方法を紹介します。

# Web Speech APIとは
各Webブラウザが提供する、音声認識機能・音声合成機能です。W3Cドラフト

## 音声認識機能
マイクからの音声をテキスト化します。Google Chrome(v25~)、Edge(v75~)、Chrome for Android(v4~)などが対応しています。Firefox、Safari、Android Browserなどについては2019年05月15日現在対応していません。
<a href="https://caniuse.com/#feat=speech-recognition" target="_blank">
<img src="https://i.imgur.com/0yL2rI8.png" />
</a>


## 音声合成機能
テキストを音声として読み上げ、スピーカーなどへ出力します。Edge、 Firefox、 Chrome、 Safari、 Opera、Firefox Androidなどが対応しています。 IE、Android 版 Operaなどについては2019年05月15日現在対応していません。
<a href="https://caniuse.com/#feat=speech-synthesis" target="_blank">
<img src="https://i.imgur.com/97Eleuj.png" />
</a>

追記(2019-05-16): Firefox Androidでは対応していないと書きましたが、誤りです。
caniuse.comと[MDN web docs](https://developer.mozilla.org/ja/docs/Web/API/SpeechSynthesis#Browser_compatibility)で対応状況に関する記述に大きな差異が見られます。情報を提供して下さった@makoto_katoさん、ありがとうございました。

# とりあえず始める
## 音声認識機能
Web Speech APIの[SpeechRecognition](https://developer.mozilla.org/ja/docs/Web/API/SpeechRecognition)インターフェイスを利用します。Google Chromeなどのwebkit系のブラウザで利用する場合は、プレフィックスが付与された`window.webkitSpeechRecognition`を参照します。

1. まず、以下をGoogle Chromeのデベロッパーコンソールで実行しましょう。

音声認識を行うために必要なことは、`webkitSpeechRecognition`インスタンスを作成し、各種設定を行った上で、`.start()`メソッドを実行することだけです。 **10行に満たないコードで音声認識ができることに感動**します。

```js
var rec = new webkitSpeechRecognition();
rec.continuous = false; // 後述
rec.interimResults = false; // trueにすると認識途中の結果も返す
rec.lang = 'ja-JP'; // 言語を指定する
rec.maxAlternatives = 1; // 結果候補の最大数(デフォルトは1)
rec.onresult = e => {
  // 認識結果がSpeechRecognitionEventインスタンスとして渡されます
  // 認識した言葉を表示
  console.log(e.results[0][0].transcript)
  rec.stop() // 認識が完了したら終了する
}
rec.start() // 認識を開始します
```

⚠ なお、Chroniumユーザの方は、音声認識機能はサポートされていない点に注意してください。

2. 次に、ブラウザに対してマイクの使用を許可しましょう。   
おそらく、以下のようなポップアップが表示されますので、これを許可しましょう。
![](https://i.imgur.com/YsDXy2F.png)

3. 喋りましょう。

4. デベロッパーコンソールに喋った内容が表示されます。

⚠なお、一度認識を行った上で、もう一度認識を行うためには、`rec.stop()`メソッドを実行して音声認識を停止した上で、再度`rec.start()`メソッドを実行する必要があります。

もしくは、`continuous`オプションを`true`にすることで、連続的にノンストップで認識し続けることができます。
この場合、ページがロードされてから現在までに認識した結果の一覧が、`webkitSpeechRecognition.onresult`へ渡されるイベント`e`の`e.results`に格納されます。
```js
var rec = new webkitSpeechRecognition();
rec.continuous = true; // <--- これ!!!
rec.interimResults = false;
rec.lang = 'ja-JP'; // 言語を指定する
rec.onresult = e => {
  // 最後に認識した言葉を表示
  console.log(e.results[e.results.length - 1][0].transcript)
}
rec.start() // 認識を開始します
```
ただし、`continuous`オプションを利用するためには、`https://`以下で実行する必要があります。無料でhttpsのWebページを提供するには、[Netlify](https://www.netlify.com/)がおすすめです。

## 音声合成機能
Web Speech APIの[SpeechSynthesisUtterance](https://developer.mozilla.org/ja/docs/Web/API/SpeechRecognition)インターフェイスを利用します。

以下を任意のWebブラウザのデベロッパーコンソール上で実行するだけで、動作が確認できると思います。   
```js
var u = new SpeechSynthesisUtterance();
u.text = "こんにちは"; // 発話する内容を指定する
u.lang = 'ja-JP'; // 言語を指定する
u.rate = 1.0; // 発話速度を指定する
speechSynthesis.speak(u); // 喋らせる
```
⚠ただし、一部のWebブラウザでは、一度ユーザがそのページでクリックなどのアクションを行った後でなければ音声合成を実行しない仕様になっています。

# 実行例
## 音声認識
[https://codepen.io/KilledByNLP/pen/dEvbvR](https://codepen.io/KilledByNLP/pen/dEvbvR)に実装・デモを公開しました。
Webブラウザの仕様上、このデモは直接ページを開かないと実行できません。

<iframe height="400" style={{width: "100%"}} scrolling="no" title="dEvbvR" src="//codepen.io/KilledByNLP/embed/dEvbvR/?height=400&theme-id=0&default-tab=html,js" frameborder="no" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href='https://codepen.io/KilledByNLP/pen/dEvbvR/'>dEvbvR</a> by KilledByNLP
  (<a href='https://codepen.io/KilledByNLP'>@KilledByNLP</a>) on <a href='https://codepen.io'>CodePen</a>.
</iframe>

## 音声合成
[https://codepen.io/KilledByNLP/pen/rgyNMw](https://codepen.io/KilledByNLP/pen/rgyNMw)に実装・デモを公開しました。
「オタク」のイントネーションがすごく気になります。

<iframe height="265" style={{width: "100%"}} scrolling="no" title="rgyNMw" src="//codepen.io/KilledByNLP/embed/rgyNMw/?height=265&theme-id=0&default-tab=js,result" frameborder="no" allowtransparency="true" allowfullscreen="true">
  See the Pen <a href='https://codepen.io/KilledByNLP/pen/rgyNMw/'>rgyNMw</a> by KilledByNLP
  (<a href='https://codepen.io/KilledByNLP'>@KilledByNLP</a>) on <a href='https://codepen.io'>CodePen</a>.
</iframe>

# 参考資料

- [https://w3c.github.io/speech-api/](https://w3c.github.io/speech-api/)
- [https://developer.mozilla.org/ja/docs/Web/API/Web_Speech_API](https://developer.mozilla.org/ja/docs/Web/API/Web_Speech_API)
- [https://www.caniuse.com](https://www.caniuse.com)

Web Speech APIはブラウザが提供する音声認識・音声合成API。無料で使えるし簡単に利用できる。

Web Speech APIなら、数行で、ブラウザ上で、無料で音声認識・音声合成ができる


## 目的

誰でも一度は独自ドメインでのメール送受信を夢見る。
しかし、わざわざメールサーバを用意するのは面倒だし、
せっかくの休日にSendmailやPostfixなどのMTA(Mail Transfer Agent)の設定と格闘するのは御免だ。

そこで、Google Domains のメールエイリアス機能を利用する。
今回は、以下の手順で簡単に Gmail 上から独自ドメインでのメール送受信を行う。

1. Google Domainsでドメインを購入/Google Domainsへドメインを移管
2. メールの受信設定
3. メールの送信設定

## Google Domainsの特徴

Google DomainsはGoogleが提供するドメイン管理サービスで、以下の特徴を備える。

### モダンでシンプルで明快なUI

ご覧の通り、物凄くシンプルだ。   
しかも、モバイルでもPCでも、同じ操作で、同じ結果が得られる。
![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-12-40-11.png)

### 明快な価格設定

Google Domainsに私たちが支払うのは、ドメインの購入・移管・更新時だけ。  
謎のオプション手数料をぶん取られることはない。  
ちなみに、.comドメインはお名前.comの方が少しだけ安い一方で、.pwドメインなどはお名前.comに対して1/3の価格で購入できる。   

### メール転送機能・プライバシー保護機能・DNS 機能が無料

当たり前のことだと思うかもしれない。  
しかし、お名前.comでは当たり前のことではなかった。
ちなみに、メールエイリアスは100個まで発行できる。
仕事用、プライベート用、捨てアド用の独自ドメインのメアドを全部Gmail上で管理できるから、本当に便利だ。

### 大量のお知らせメールが届かない

お名前.comからのお知らせメールには不思議な魅力がある。

午前中に3件も届いた素敵なメールは、脳にアドレナリンを分泌させ、冷蔵庫を何度も何度も蹴飛ばしたくなるような活力を与えてくれる。
まさに読むエナジードリンクだ。ちゃんと読んだことないけど。

Google Domainsに移管した結果、残念ながらその素敵なメールは二度と届かなくなった。

## Google Domainsでドメインを購入する

もしドメインを持っていないなら、[Google Domains](https://domains.google.com/m/registrar/search?hl=ja&authuser=0)から購入しよう。

まず、欲しいドメインで検索し、カートに追加したら、カートに移動する。
![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-00-15.png)
次に、「精算」をクリックすれば、購入完了だ。
![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-02-09.png)

## Google Domainsへドメインを移管する

もし既にドメインを持っているなら、Google Domainsへ移管しよう。

### お名前.comをご利用の場合

[お名前comからgoogle domainsにドメイン移管する - Qiita](https://qiita.com/fnifni/items/0daca17e0750659f2866)

### ムームードメインをご利用の場合

[co.uk ドメインをムームードメインから Google Domains へ移管する - with a Christian Wife](https://blog.withachristianwife.com/2018/07/29/transfering-co-uk-domain/)

## メールの受信設定
まず、独自ドメインでメールを受信する設定を示す。
[ドメイン管理画面](https://domains.google.com/m/registrar/?hl=ja&authuser=0)を開き、「管理」をクリックする。
![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-15-33.png)

次に、メールの転送元と転送先を設定する。
![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-19-16.png)


## メールの送信設定
### 二段階認証の設定
この機能を利用するにはGmailを利用しているGoogleアカウントに二段階認証を設定する必要がある。
[二段階認証の設定画面](https://myaccount.google.com/signinoptions/two-step-verification?utm_source=google-account&utm_medium=web) に移動し、設定する。

### アプリパスワードの設定
次に、アプリパスワードを設定する。
[アプリパスワードの管理画面](https://myaccount.google.com/apppasswords)に移動し、以下のように設定し、アプリパスワードを取得する。

![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-31-19.png)
![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-35-04.png)
![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-36-25.png)

### メールアドレスの追加

最後に、Gmailの[アカウント設定画面](https://mail.google.com/mail/u/0/#settings/accounts)からメールアドレスを追加する。

まず、「他のメールアドレスを追加」をクリックする。
![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-44-00.png)
次に、送信元にしたいメールアドレスと名前を入力する。
![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-47-14.png)

最後に、SMTP サーバー、ポート、ユーザー名、パスワードを入力する。
* SMTP サーバー   
smtp.**gmail**.com
* ポート   
465
* ユーザー名   
**Gmail**のメールアドレス(example@gmail.com)
* パスワード   
先程取得したアプリパスワード

![](/assets/posts/g-mail-by-your-own-domain-with-google-domains/2019-02-10-13-57-01.png)

これで、設定は完了となる。

## おわりに
最後に、設定した独自ドメインでメールを送受信できるか確認する。

Google Domainsで独自ドメインを管理すれば、簡単に独自ドメインでGmailでの送受信が行える

独自ドメインでのメール送受信をGoogle Domains + Gmailで簡単に実現


## はじめに

Yahoo! ジオシティーズは、2019 年 3 月末を以てサービスを終了する。
これにより、2000 年代に作成された多くの貴重なコンテンツたちの閲覧が難しくなってしまう。

そんな時に、ウェブアーカイブサービス（通称：魚拓サービス）が便利だ。
魚拓サービスは、Web ページをキャッシュとして半永久的に保存・閲覧できるサービスだ。

今回は、そんな魚拓サービスを利用して、ワンクリックで魚拓を閲覧・保存するブックマークレットを導入する方法を紹介する。

## おことわり

本記事では、主に PC の利用者を対象に解説している。
モバイルでもこのブックマークレットは動作するが、導入方法・利用方法については以下の外部サイトを参考にされたい。  
[iPhone の Safari にブックマークレットを登録する設定手順](https://rezv.net/iphone/9352/)

## 導入方法

### #1 ブックマークバーを表示する

アドレスが表示されている欄の下に、ブックマークの一覧が表示される部分が「ブックマークバー」だ。
![](https://i.imgur.com/tuVmGex.png)
ブックマークバーが表示されていない場合は、以下を参照し、ブックマークバーを表示させる。  
[Firefox の場合](https://support.mozilla.org/ja/kb/bookmarks-toolbar-display-favorite-websites#w_ciccagczckagceckcecackacaecjaaaaagyzaecjaeaoao)  
[Vivaldi/Chrome/その他 Chronium 系の場合](https://support.google.com/chrome/answer/188842?co=GENIE.Platform%3DDesktop&hl=ja)
[Safari の場合](https://support.apple.com/ja-jp/guide/safari/ibrw1012/mac)

### #2 ブックマークレットをブックマークに保存する

#### Firefox・Vivaldi の場合

<p>
FirefoxかVivaldiを利用している場合は、以下のリンクをブックマークバーにドラッグドロップするだけで良い。
</p>
<p>
<a href='javascript:window.open("https://web.archive.org/save/"+location.href)'>保存</a>
&nbsp;&nbsp;&nbsp;/&nbsp;&nbsp;
<a href='javascript: window.location.href="https://web.archive.org/web/*/"  + window.location.href'>閲覧</a>
</p>

![ドラッグドロップで上記URLを保存して下さい](https://i.imgur.com/ZA9AFwH.png)

#### Chrome の場合

残念ながら、Chrome の場合は少し面倒だ。

1. まず、下記の保存用スクリプトをコピーする。

```js
javascript: window.open('https://web.archive.org/save/' + location.href)
```

2. Windows の場合は Ctrl+D を、macOS の場合は Command+D を押す。
3. 「その他...」を押す。
   ![](https://i.imgur.com/RhCfdBX.png)
4. 下記の通りに入力し、保存する。
   ![](https://i.imgur.com/o50Gjlp.png)
5. 最期に、下記の閲覧用スクリプトをコピーし、同様の手順を繰り返す。

```js
javascript: window.location.href =
  'https://web.archive.org/web/*/' + window.location.href
```

## 利用方法

ブックマークバー上からクリックするだけで良い。
試しに、この記事を保存・閲覧してみて欲しい。

## おわりに

不具合のご報告・修正依頼は、[twitter.com/ebiebievidence](https://twitter.com/ebiebievidence) か[GitHub Issue](https://github.com/ebiebievidence/blog)までお気軽にどうぞ。


ワンクリックで魚拓を閲覧・保存するブックマークレットの紹介

魚拓をかんたんに閲覧・保存できるブックマークレット


## TL;DR

```sh
tmux ls
tmux new -s $SESSION_NAME
tmux attach -t $SESSION_NAME
```

を

```sh
t
t $SESSION_NAME # new
t $SESSION_NAME # attach
```

とするエイリアスを紹介する。
きっと色々なツッコミがあるかとは思うが、ぜひ温かい目で見守ってほしい。

## 悩み

前述の 3 つの頻出イディオムは、打つのが中々に面倒だ。
賢明な読者各位は、例えば以下のようなエイリアスを張っていると思う。

```

alias ta='tmux a -t '
alias tn='tmux new -s '
alias tls='tmux ls '

```

しかし、私は非常にズボラで、tmux new と tmux attach をわざわざ使い分けることすら面倒になった。

## 解決策

### ズボラエイリアス

様々な方面から怒られるかもしれないが、私は以下のようなエイリアスを貼っている。

```
t () {
	tmux attach -t $1 2> /dev/null || tmux new -s $1 2> /dev/null || tmux ls
}
```

このようにすることで、tmux ls も、tmux attach も、tmux new も t で完結させることが出来る。

試したい方は、~/.bashrc なり~/.zshrc なりに上記を書き足して頂いた上でターミナルを再起動するなりして設定を反映して、試してみて欲しい。

### ズボラ補完

また、zsh の補完機能のために、以下も書き加えている。

```zsh
_t() { _values 'sessions' "${(@f)$(tmux ls -F '#S' 2>/dev/null )}" }
compdef _t t
```

このようにすることで、以下のように簡単に各セッションに接続できる。

![](https://i.imgur.com/FKdeJJw.png)

## おわりに

何だかこのめちゃくちゃなエイリアスは、きっと何か問題を抱えている気がする。何かマズいことに気が付かれた方は、ツイッターかはてなブックマークで問題点を共有して頂けると嬉しい。


tmux new -s $SESSION_NAME、tmux attach -t $SESSION_NAME...あの長くて面倒なコマンドたちを、すべて1文字のコマンドに集約する方法

tmuxのls, new, attach を1文字で完結させるズボラなエイリアス


## 本記事のねらい

`Python 3.6.3` における `json.dumps` が、 `np.isnan() == True` となるような値を `nan` として出力する問題を、外部ライブラリ`simplejson`によって解決する。

## 問題

- Pandas では欠落値を`np.nan`として保存する
- これを`json`ライブラリを用いて出力すると、以下の通り出力の中に「nan」が紛れ込んでしまう。
  RFC8259 にもあるように、NaN は許可されない。欠落値であるならば、せめて`null`として出力されるべきだ。

```json
[
  {
    "id": 1,
    "body": "yo",
    "parent_id": nan
  }
]
```

## 解決法

Python の標準ライブラリ`json`は、`simplejson`を取り込んだものである。しかし、`simplejson`は標準ライブラリ`json`よりも頻繁にアップデートされていて、機能・速度共に標準ライブラリに勝る。

`simplejson`の`dumps`は、`ignore_nan`という引数を持つ。

`pip install simplejson` でインストールした後、次のように書けばいい。

```python
import numpy as np
import simplejson as json

numbers = [np.nan, 1, 2, 3]

json.dumps(numbers, ignore_nan=True)
```

すると、次のような結果を得る。

```json
[null, 1, 2, 3]
```


jsonライブラリよりも、simplejsonライブラリの方が便利という話

Python 3.6.3 の json.dumps が、np.nan をそのまま nan として出力する問題の解消


## はじめに

Python3.3 までは、 **「あるディレクトリ以下に存在するテキストファイルの一覧を取得して、それぞれを開く」** という処理に、以下の 3 つのライブラリを使う必要がありました。

- ファイルパス操作  
  os.path
- ファイルの一覧取得  
  glob.glob
- ファイルを開く  
  open

しかし、Python3.4 以降であれば、これらを **すべて 標準ライブラリ`pathlib`に一任** することができます。  
これによって、ファイル操作処理における **書きやすさ・読みやすさが向上** し、それぞれのライブラリの使い方をわざわざ調べる時間や、 ライブラリ間の微妙な仕様の違いに苛まれる心配から解放されます。

今回は、 **「`../datasets/foo/bar`以下に存在するテキストファイルをすべて取得して、内容を表示したい」** という目標に対して、pathlib を利用しない場合、pathlib を利用する場合のコードを比較しましょう。

## pathlib を利用しない場合

まずは、os.path、glob.glob、open を使った場合のコードを見てみましょう。

```python
import glob
from os.path import join, dirname, abspath

current_dir = dirname(abspath(__file__))
datasets_dir = join(dirname(current_dir), 'datasets', 'foo', 'bar')
file_names = glob.glob(join(datasets_dir, '**/*.txt'), recursive=True)

for file_name in file_names:
    with open(file_name, 'r') as f:
        print(f.read())
```

#### 問題: パッと見て、どこを指しているのか分からない

**あなたは、以下のコードを見て、これがどこを指しているのかすぐに分かりますか？**

```python
current_dir = dirname(abspath(__file__))
datasets_dir = join(dirname(current_dir), 'datasets', 'foo', 'bar')
```

普段、私達はディレクトリパスを左から右に読みますし、英語や日本語も左から右に読みます。しかし、join や dirname や abspath を使うと、そのコードがどこのパスを示しているのか、左から右にスラスラ読むことはできません。

## pathlib を利用した場合

```python
from pathlib import Path

current_dir = Path.cwd()
datasets_dir = current_dir.parent / 'datasets' / 'foo' / 'bar'
file_names = datasets_dir.glob('**/*.txt')

for file_name in file_names:
    print(file_name.read_text())
```

### 良いところ 1: 読みやすい

pathlib を用いた場合、普段我々がディレクトリパスを読む時にそうしているように、左から右にディレクトリパスを追うことができます。

```python
current_dir = Path.cwd()
datasets_dir = current_dir.parent / 'datasets' / 'foo' / 'bar'
```

は、「現在のディレクトリの、親の、'datasets'の中の...」と、まさにそのまま左から右にスラスラと読むことができます。また、pathlib では`/`演算子でパスを結合することができます。慣れないと少し気持ちが悪いかもしれませんが、読みやすいことは間違いありません。

#### 追記

```python
## 方法1
current_dir = Path.cwd()
## 方法2
current_dir = Path(__file__).resolve().parent
```

上記は、場合によってはそれぞれ異なる結果を返します。
「方法 1」はスクリプトを実行した時に位置していたディレクトリ、「方法 2」は実行されたスクリプトの存在するディレクトリを指します。

### 良いところ 2: ちょっとしたことで色々なライブラリをインポートしなくていい

```python
file_names = datasets_dir.glob('**/*.txt')

for file_name in file_names:
    print(file_name.read_text())
```

pathlib を使用する場合、上記のような処理のためには glob と os.path の両方をインポートする必要があります。
pathlib を使用すれば、ファイルの一覧の取得も `datasets_dir.glob('**/*.txt')`で一発です。  
また、ファイルの書き込み・読み込みも、`open`で得たファイルオブジェクトの終了処理を気にせずに、気軽に`read_text()`、`write_text()`、`read_bytes()`、`write_bytes()`で行えます。

## おわりに

他にも、詳しいことはすべて https://docs.python.jp/3/library/pathlib.html に記されています。本当に便利です。こちらもぜひ一度ご覧になってください。

ご意見・ご指摘お待ちしております！

## 追記

色々な反応を頂きましたので、せっかくですからいくつかピックアップして紹介します。

### /が連結演算子ってキモい

僕も最初はそう思ったクチなので気持ちは良くわかるんです。ただ、演算子のオーバーロードは Python のみならず、Ruby、C++、Swift、Kotlin、D などでもサポートされていることから、よくよく考えるとそこまで変な話ではないと思います。個人的には、set の和演算子 `|` や 部分集合判定演算子 `<=` も初めはビビりました。

### 可読性、あんまり変わってなくない？

これはかなり意外な意見でした。私はディレクトリを指定する時は「このディレクトリの、親ディレクトリの、…」と考えるのですが、pathlib ではその直感に沿って右から左に書けるから、書きやすさや読みやすさは向上していると感じましたが、ここは人それぞれといったことでしょうか。


ebiebievidence.com

私について

人気の記事

Go コンパイラのコードを読んでみよう

独自ドメインでのメール送受信をGoogle Domains + Gmailで簡単に実現

ISUCON10 予選敗退の記録と反省

すべての記事

ペーパードリップの初心者が安定してコーヒーを淹れるための方法と道具

BigQuery の課金額で泣かないための UserScript

このブログを Gatsby + Remark から Next.js + MDX + Contentful へ移行しました

それでも .env を env したい

Go コンパイラのコードを読んでみよう

ISUCON10 予選敗退の記録と反省

二者間交渉ゲームにおける交渉解の比較

Web Speech APIなら、数行で、ブラウザ上で、無料で音声認識・音声合成ができる

独自ドメインでのメール送受信をGoogle Domains + Gmailで簡単に実現

魚拓をかんたんに閲覧・保存できるブックマークレット

tmuxのls, new, attach を1文字で完結させるズボラなエイリアス

Python 3.6.3 の json.dumps が、np.nan をそのまま nan として出力する問題の解消

os.path から Pathlib に乗り換えよう