## 概要

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

以下では御託をつらつらと並べておりますが、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 class="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 class="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 予選敗退の記録と反省

すべての記事

このブログを 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 に乗り換えよう