
岩本海童(いわもとかいどう)です。
福岡に住んでいるソフトウェアエンジニアです。

## 作ったものとか

- [Kakeru](https://about.kakeru.app/ja): 共同編集可能なホワイトボード的な Web アプリ
- [Reversi](https://reversi.odiak.net): JavaScript で書かれたリバーシのゲーム

## リンク

- Twitter: [@odiak\_](https://twitter.com/odiak_)
- GitHub: [odiak](https://github.com/odiak)


自己紹介


SPAのリンクをTwitterやFacebookでシェアした際に、OGPによるプレビューを表示させたいが、
SSRするほどでもない場合のやり方を考えてみた。

## 前提

- 完全に静的なHTML, JavaScript, CSSだけで構成されたシングルページアプリケーション。
    - Next.jsのSSRなどを使っていない。
- それらの静的なファイルはNginxで配信されている。

Nginxの設定はこんな感じ。(リクエストに該当するファイルが存在しない場合は/index.htmlを返す)
```
server {
    server_name example.com;

    root /path-to-static-files;

    if (!-f $request_filename) {
        rewrite (.*) /index.html;
    }
}
```

## やり方

### 1. HTMLファイルにOGPのタグを付けて返すアプリケーションをNode.jsとExpressで作る

次のコードのような感じ。

元のアプリケーションのパスに/ogpというプレフィックスをつけたものでリクエストを受けると、
HTMLにそのページのOGPタグを付けて返す。
(プレフィックスはなんでもよい。付ける理由は後述する。)

HTMLは、どこかのファイルから読んでくる。
ここではシンプルに決まったファイルを読んでいるが、疎結合にするためにパスをヘッダーで指定したり、ネットワーク経由で読み込んでも良いと思う。

OGPタグを付ける処理は、HTMLの`</head>`を`<meta ... />...</head>`で置き換えるという雑な実装。

```ts
import express from 'express'
import { createServer } from 'http'
import { readFile } from 'fs/promises'

const app = express()

async function getPost(slug: string): Promise<{title: string}> { /* ... */ }

// OGP for post pages
app.get('/ogp/posts/:slug', async (req, res) => {
    // OGP
    const slug = req.params.slug
    const html = await readFile('/path-to-static-files/index.html', 'utf-8')
    const post = await getPost(slug)
    res.send(html.replace('</head>', `
        <meta property="og:title" content="${post.title}"/>
        <meta property="og:type" content="article"/>
        <meta property="og:image" content="https://example.com/image.png"/>
        <meta property="og:url" content="https://example.com/posts/${slug}"/>
        <meta property="og:site_name" content="My Website"/>
        <meta name="twitter:card" content="summary"
    </head>`))
})

// OGP for category pages
app.get('/ogp/categories/:page', async (req, res) => {    
    // ...
})

// default OGP
app.use('/ogp/:anything*', async (req, res) => {
    // ...
})

createServer(app).listen(8000)
```

### 2. Nginxの設定を変更する

こんな感じ。
/foo/barでリクエストが来たときに、/foo/barというファイルが存在しなければ/ogp/foo/barでlocalhost:8000にプロキシしたものを返す。
```
server {
    server_name example.com;

    root /path-to-static-files;

    if (!-f $request_filename) {
        rewrite (.*) /ogp$1;
    }

    location /ogp {
        proxy_pass http://localhost:8000;
    }
}
```

これでリクエストのパスに応じてOGPのタグがついたHTMLが返ってくるようになった。万歳！

---

まあこのままでも問題はないが、もう一工夫してみる。

OGPの生成に多少の時間がかかる場合、このやり方では読み込みの時間が長くなり、アプリケーションのパフォーマンスに影響してしまう。
アプリケーションのユーザーにとってはOGPタグは必要ないわけだし、省略できる時は省略したい。

そこで考えたのが、クッキーを利用する方法。
フロントエンドであるクッキーに値を設定し、そのクッキーが設定されている場合は直接静的ファイルを返すのである。

### 3. フロントエンドでクッキーを設定する

アプリケーションのどこかに次のようなコードを入れておく。
```ts
document.cookie = `no_ogp=1; max-age=${60 * 60 * 24 * 365}`
```

### 4. Nginxの設定を再度変更する

次のように、`location /ogp` の下に、if文を追加する。
`no_ogp`というクッキーに空ではない値が設定されていれば、OGPタグを付ける処理をスキップして直接HTMLファイルを返す。
(rewriteの最後にlastを付けないと、rewriteしたものがproxy_passに渡ってしまう。)
```
server {
    server_name example.com;

    root /path-to-static-files;

    if (!-f $request_filename) {
        rewrite (.*) /ogp$1;
    }

    location /ogp {
        if ($cookie_no_ogp) {
            rewrite (.*) /index.html last;
        }
        proxy_pass http://localhost:8000;
    }
}
```

はい、これで初回のリクエスト以外はOGPタグを付ける処理をスキップすることができ、アプリケーションのパフォーマンスにほぼ影響がなくなりました。
めでたしめでたし。

## まとめ

- SPAにOGPタグをつけるためにNext.jsなどを使うのはかったるいので、専用のミニアプリケーションを作ってそちらでタグを付ける処理をしてみた。
- クッキーを使ってタグを付けるかどうかを制御すると、アプリケーションのパフォーマンスにも影響しない。

お読みいただきありがとうございました。
こちらは、[Web上のホワイトボードアプリ: Kakeru](https://about.kakeru.app/ja/)を開発中に思いついたアイデアで、実際にアプリケーションで使用しています。
よかったらKakeruの方も使ってみてください。


動的なOGPが欲しいけどSSRするほどでもない場合にやったこと


今までノートをとるためのソフトウェア・サービスは色々使ってきた。

- Evernote
- Simplenote
- Google Keep
- Scrapbox
- Inkdrop
- Obsidian

使ってきたツールはどれも良いものだったけど、ちょっとした不満があったり、他のツールに目移りして違うのを使ってみたり、
という感じで渡り歩いてきた。

最近は、Google Driveのフォルダにmarkdownファイルを入れて、VSCodeで編集するというスタイルで落ち着いてきた。
今日はその話を書いてみる。

## Inkdrop

去年はInkdropを使ってた。
作者の人がブログやTwitterなどで情報発信しているのを見て、以前から試してみようと思っていた。

アプリはよくできていて使いやすかった。

Scrapboxいいよなーと思っていたが、markdownも良いものだと改めて思った。
書いたものを他の場所(GitHubだったりブログだったり)に直接持っていけるのが良い。

ところがふとある時、このノート内でブログの投稿も管理したいなと思うようになった。

それまでは、このサイトの投稿はGitのリポジトリで管理していて、下書きをInkdropで書いていた。
そうすると下書きをGitに移動する手間が少々かかる。
デプロイ時にノートのデータを引っ張ってきたら楽になるんじゃないか？と思った。

しかし、Inkdropのデータはアプリの外から扱うのが難しい。
なぜならE2E暗号化されているから。
アプリをリバースエンジニアリングして、仕組みをある程度理解したけど、面倒で心が折れた。

ロックインされないためにも、データはファイルシステムに置いておくのが良いのでは？と思うようになった。
karino2さんもそういう話を書いていた気がして、以前はピンと来なかったけど、やっとその良さがわかった。

## Obsidian

さて、以前から気になっていた別のノートのアプリでObsidianというものがあった。
Scrapboxと似たページ間リンクの仕組みがあると聞いていた。(というかリンク記法自体は特に新しいものではなく、Wikiなどにもあるけど。)
独自のクラウドによる同期の仕組みもあるが、ファイルシステム上でデータを管理することもできて、大満足。

これでブログの問題は解決した。(詳細は後述)

しばらく使っていると、また小さな不満が。
といっても、もう具体的に何だったのか忘れてしまっているくらい小さな事だったんだけど。
あ、複数のノートをタブで開きたいとかだったかな。

色々考えていると、VSCodeがいいんじゃないの？と思うに至った。
ロックインされていないとこういうのが楽で良い。

VSCodeの設定をいじったり機能拡張を入れたりすると概ね快適なノート編集環境ができあがるんだが、
Obsidianに搭載されているページ間のリンク記法は使えない。
ちょうど少し前にVSCodeの機能拡張を作る実績を解除していたので、自分で機能拡張作るか！となった。

## ブログの投稿をノートのサブディレクトリに入れる運用

`blog`というフォルダと、`blog-draft`というサブフォルダを作っておく。
ブログの下書きは後者に入れておき、公開するときに前者に入れてデプロイする。
記事を公開後に編集するときは、ただファイルを書き換えてデプロイすれば良い。

このブログはNext.jsで書かれており、Vercelにデプロイされている。
ビルド時に投稿データをあるディレクトリにダウンロードしておき、そこからコンテンツを読んでレンダリングする。

Google Driveからファイルをダウンロードする際には、Google Drive APIとGoogle Cloudのサービスアカウントを使っている。
投稿が入っているディレクトリを、専用のサービスアカウントに読み込み専用で共有しておく。
そうすることで、OAuthを使って認証するのに比べると実装が楽だし、ミスやキーの漏洩によるデータの書き換えも防げる。

デプロイは、めっちゃ簡単にできるようになっている。
Vercelにはプロジェクトごとにデプロイ用の秘密のURLが用意されており、そこにHTTPリクエストを送るとデプロイが走るようになっている。
そのURLをノートに貼ってあるので、リンクを踏むだけでデプロイされる。

このブログのシステム、なかなかよくできたなと我ながら思うんだけど、どうですかね？

## VSCodeの機能拡張でObsidianの機能を実現する

まだかなり未完成でかなり荒削りだけど、Obsidianで使われているリンク記法などをVSCodeで実現する試みをやっている。

https://github.com/odiak/vscode-wiki

エディタとプレビューでリンク記法をクリックしてジャンプできるようになっているし、
サイドバーにこのページからのリンクとこのページへのリンクのリストを表示できるようにもなっており、
かなり完成に近づいてきている。

最終的には、ページ間のリンクをグラフとして表示する機能も実装できたらいいなと思っている。
詳しい技術的な話は一通り完成してから改めて書きたい。

markdownのプレビューに関していうと、VSCodeの内部ではMarkdownItというJSのライブラリが使われていて、
それのプラグインを書いている感じ。
他の部分は、VSCodeのAPIを駆使して色々やっている。
VSCodeのドキュメントが充実しているのは本当にありがたいし、公開されている機能拡張はオープンソースなことが多いのでソースを読んで参考にしたりもできる。

興味がある方は自分でビルドして使ってみてください。

## スマホアプリはどうするのか

これが一つの問題でして、今のところはObsidianを使っている。
Google Driveのフォルダは、サードパーティの同期用のアプリを使ってストレージに同期させている。

スマホでノートを編集するとたまにコンフリクトが起きていることがあったりという煩わしさがあるので、
そのうちアプリも自分で作ってみようかと思っている。

---

というわけで、Google DriveとVSCodeでノートとってるよという話でした。
VSCodeはいいぞ！！


Google DriveとVS Codeでノートをとる話


先日、友人にOculus Quest2をもらった。
以前からなんとなく気になってはいたが、ゲームをやりたいとはそこまで思っていなくて、それなら買うほどでもないかなと思っていた。

## いくつかアプリを試す

セットアップしてから、YouTubeとNetflixとVRChatと、あとはNational Geographicのアプリ(有料)を入れてみた。

- YouTube: 360度の動画は面白いけど、動きがあると若干酔う
- National Geographicのアプリ: 遺跡や自然の中に立って動き回れるが、あまりパッとしない感じ
- VRChat: 部屋に入ってうろうろして、鉢合わせた人と挨拶しただけ。操作に慣れると面白そう
- Netflix: 前に画面があるだけだが、非常に良い。周りが暗くて集中できるし、画面も大きいし

少し脱線するけど、OculusのNetflixでイカゲームを見た。
めっちゃ面白かったです。

## Immersed

もう一つ、以前から使ってみたかったのが[Immersed](https://immersed.com/)というバーチャルデスクトップのアプリである。
これはPCのディスプレイをバーチャル空間中に設置できるというものである。
ディスプレイは、追加することもできる。(無料だと1つまで、お金を払うと最大5つまで。)
大きさや配置は自由に変更できるので、実際の机が狭くても、実際のディスプレイが狭くてもバーチャル空間でマルチディスプレイ環境を実現できる。

azuさんがブログで紹介していたのを見て知り、興味を持ったがきっかけ。
[Immersed \+ Meta Quest$Oculus Quest$ \+ Macbook Proで、文章やコードを書く \| Web Scratch](https://efcl.info/2021/10/30/immersed/)

使ってみると、これはなかなか良いものである。
なんというか普通に良くて、特に不便なところも見当たらない。

ただ、やっぱりOculusはしばらく着けていると疲れないこともない。
それもNetflixを見る分には気にならないが、仕事などの場合は集中の妨げになってしまう感じがある。
あと、ディスプレイとして使うならもう少しヘッドセットの解像度が欲しい。
今のところ、目の前に程よい大きさで画面を表示すると、文字が少し滲んでしまう。
画面をもう少し大きくすればいいのかな〜。

## つけ心地改善グッズ

Oculusを少し使ってみて、つけ心地がイマイチだったので、追加のアクセサリーを買ってみた。

- [Quest 2 Eliteストラップ](https://www.oculus.com/accessories/quest-2-elite-strap/)
    - 頭が疲れにくくなるやつ
    - 後頭部でもOculusの重さを支えることができて、調節用のダイヤルがついている
- [Oculusシリーズ対応 反射防止コート 度付きレンズ アタッチメントセット$OQC\-001$ 乱視対応 収納ケース付き](https://www.amazon.co.jp/dp/B08TT3JVQN)
    - 眼鏡をつけなくても良くなるやつ
    - 眼鏡をつけてOculusを装着すると、着脱も少し大変だし、Oculusのずれと眼鏡のズレの両方に気をつける必要があり面倒

どちらもかなり良かったと思う。
度入りレンズは、視界の周囲が少しボケるのも解消できるかなと思ったが、それはあまり変わらなかった。

## まとめ

Oculus Quest2をもらったのでゲーム以外を色々やってみた。
バーチャルスクリーンのImmersedはなかなか良かったので、ぜひ試してみて欲しい。
快適に使うなら、Eliteストラップと(眼鏡かけている人は)度入りレンズの使用をおすすめする。

ゲームもそのうちやってみたい。


ゲームをしないVR


以前はVimやVimのキーバインドを使っていたんだけど、少し前から使うのをやめてみた。
今日はその話を書いてみたいと思う。

## Vimの思い出

僕がVimを使い始めたのはおそらく2011年くらいだった。
使い始めた理由としては、ネットで存在を知ってかっこいいと思ったことと、Linuxサーバーを操作するときにviでファイルを編集するのが当たり前のような雰囲気があったこと、の2つが大きいと思う。

途中で他のエディタも試したりしつつ、長い間Vimをメインのエディタとして使っていた。
Twitterやブログ記事などを見て、プラグインを入れてみたり設定を変えてみたりした。
といっても、なかなか超使いこなせているという感じになれなかったし、マウスやカーソルキーなどを使った操作も積極的に使っていた。
そして、Vim scriptという言語に関しては最後まで慣れることができなかった。

(余談だけど、友人の一人にVim scriptからプログラミングを始めたという人がいて、こいつは相当な曲者だなと思ったことがある。)

そんな中で、自分のVim操作の熟練度を少し上げてくれたのが[「実践Vim 思考のスピードで編集しよう！」](https://www.kadokawa.co.jp/product/311865500000/)という本だった。
この本は、最初はドットコマンド(`.`)のすごさから始まり、コマンドが操作と操作対象から構成されていることや、マクロなどについて説明していた。
この本を読んで、「おー、Vimってこうやって使うのか。これは楽しい！」と感動したのを覚えている。
ツイート探したら2013年だった。

> 実践Vimやばい！！
https://twitter.com/odiak_/status/379126664891883520

> 公園で実践Vim読んでます
https://twitter.com/odiak_/status/379127617019854848

実践Vimは、Vimの活用方法を知りたい人がいればおすすめしたし、一度人に貸したこともある。それくらい良い本だった。

そんな感じで、その後しばらくはVimをターミナルから、あるいはGUI版のものを使っていた。
Androidの開発をやっていたときはさすがにAndroid Studioを使ったけど、IdeaVimという機能拡張を入れてVimキーバインドにしてた。

でも、IDEなどのVim拡張はショートカットキーとVimのコマンドが衝突してしまうことや、本物のVimと微妙に違う動きをすることなどがあり、少しストレスを感じるポイントだった。

2017年か2018年くらいに、GitHubが開発したAtomというエディタがかなり流行っていたので、試してみた。
もちろんVim風の機能拡張も入れた。
GUIは使い勝手が良いしそこそこ満足ではあったが、一つ不満に感じたのが、プロジェクトごとに設定を変更できなかったこと。

Atomの人気とは少し遅れて、Microsoftが開発したVS Codeというのも使われ始めていた。
Atomに不満を感じていたので、こちらを試してみたところ、ちゃんとプロジェクト毎に設定を変更できたので乗り換えた。
VSCodeの方が軽いと言われていたけど、僕はそこまで違いを感じなかったし、操作感なども似ていたと思う。(当時はそこまでヘビーに使っていなかったからかもしれない。)

そんな経緯を経て、メインのエディタをVimからVSCodeに乗り換えた。
もちろんVimの機能拡張(VSCodeVim)は入れていた。

さて、今年の初めくらいに、ふと思い立ってVimのキーバインドを外してみた。
特に何か心境の変化があったわけではないが、後述するちょっとした不満が長年たまっていたのかもしれない。

> 最近、Vimキーバインドがなくても普通にコードかけるかもしれないと思い始めている。新しい環境とかで、面倒だから標準のキーバインドで使ったら意外と悪くないじゃん、的な感じで。
https://twitter.com/odiak_/status/1364465456426283008

> Vimをやめてみるの面白い。モード切り替えがなくて日本語書くのが楽になるなーというのはある反面、ノーマルモードのちょっとしたコマンドが恋しくなる。surround.vimなどの括弧や引用符を扱うやつが特に。
https://twitter.com/odiak_/status/1364833652262113281

最初は、使い慣れたコマンドが使えなくて少々ぎこちない感じだったが、徐々に慣れて、すぐに普通にコードが書けるようになった。

というわけで、僕のVimライフはあっさりと終わりを迎えてしまった。

今でも、SSHなどでリモートのマシンにあるちょっとしたファイルを編集するときなどにVimを使うことはある。
操作も覚えているので特に不自由はないが、その機会はかなり稀になってしまった。

## Vimの不満点

Vimの軽量さや、キーボードを使ってファイル内を移動したり、テキストを操作したりする感じは気に入っていたが、いくつかの不満点があった。

### モードがあるので、日本語を入力するのが辛い

普段はノーマルモードと挿入モードを交互に切り替えながらテキストを編集するわけだが、日本語の文章を書こうとすると、挿入モードに切り替えてからIMEを日本語に切り替えなくてはならない。
逆に、ノーマルモードに戻る時も、IMEを切り替えてから戻る必要がある。
そのせいで、日本語を書くときにかなりのストレスを感じることになる。

VSCodeVimでは、これを解消するための仕組みが用意されていた。
IMEを切り替えるコマンドラインツール(im-select)を用いて、ノーマルモードに戻る際にIMEの言語を指定したものに設定してくれる。
そして、再び挿入モードに切り替えると、前回と同じ言語に戻してくれる。

しかし、macOSでしばしばそれが正しく動かないのである。
macOSの問題のように感じたが、IMEが切り替わったように表示されるものの実際には切り替わっていないのである。
少し残念、というか何回かに一度使えないものは全く使えないのと同じといって良い。

というわけで、日本語を書くのが辛いのはかなり痛い！

### テキストベースのUIが貧弱に感じられる

Vimでもウインドウを分割できるし補完も出せるしファイルツリーも表示できるんだぞ！と思っていたけど、AtomやVSCodeを使ってみると世界が違う。

やはりCUIはかなり制約が強いもので、同じサイズのフォントしか使えないし、画像などを表示することもできないし、マウスでの操作などにも限界がある。

### Vimのキーバインドが使えない環境でテキストを入力するのがやや苦痛になる

まあ、これはそこまで大きな理由でもないか。

ブラウザやその他のアプリでちょっとしたテキストやコードを書くことはよくあるわけだが、その際にすぐVimのことを考えてしまう。
Vimで編集したテキストをコピペしたり、場合によってはVimキーバインドが使えるように設定したりすることもできるが、そこまでするほどか？と思ったりする。

あと、最近はマシンを買い替えたりした際にセットアップが面倒なので、各種アプリケーションやツールはできるだけ少ない設定で使いたいと思うようになってきた。
Vimの拡張をあちこちに入れてしまうのは、それに反してしまうことにもなる。

## まとめ

Vimを使い始めたきっかけにはじまり、長い間メインのエディタとして使っていたVimからVSCode+VSCodeVimに乗り換え、最終的にはVSCodeVimを使うのをやめてしまうまでの経緯を書いてみました。

Vimをやめた結果、かなり快適にコードが書けるようになりました。
僕にはVimは向いていなかったのかもしれません。

(当然ですが、ここに書いたことはあくまで僕の個人的な感想であって、VimやVimのユーザーを否定するつもりはありません。)


Vimを使うのをやめた理由


今年のはじめくらいからInkdropでメモなどを書いてたんだけど、最近Obsidianに移行している。
詳しい感想とかは別で書く予定だが、データをGoogle Driveの1フォルダに置いているので、自由な感じがあって良い。

前からやりたかったんだけど、それらのメモとブログを統合してみた。
具体的には、`blog`というフォルダがあって、その中に書いたmarkdownファイルがブログになるというもの。

この記事もAndroidのObsidianで書いている。
メモとして個人的に書いたものをサッと公開したりというのが楽になるのではと思っている。

以前はGitHubのリポジトリにmarkdownファイルが入っていたんだけど、それをデプロイの度にGoogle Driveから落としてくるようにした。

という感じで、とりあえずやってみます。


ブログとノートを統合してみた


Audibleというオーディオブックのサービスが微妙に複雑な課金モデルになっているのでまとめ的なメモを書いておく。

- サブスクに加入しなくても本を買って聴くことはできる
  - ただし少し高い
- サブスク
  - 毎月1枚コインがもらえて、1枚で1つの本と交換できる
  - 月1200円くらい
  - 月替わりで、加入してる人が無料でもらえる本がある
    - 自動的にもらえるわけではなく、自分からアクションを起こす必要がある
  - 追加でコインを買うこともできる
  - サブスクから退会しても聴くことはできる
    - ただし退会するとコインは消える
  - 一時的にサブスクを休会することができる
    - ただし1年に3ヶ月しか休会できない
    - 休会している間はコインが消えない

## おすすめの使い方

- サブスクに加入して、欲しい本を買う
- 欲しい本を買い終わったら、退会する
  - うっかり加入したままにしておくと、コインが増えてしまい、またコインを消費しなくてはいけなくなる

間違っていたらTwitterなどで教えてください。


Audibleについてのメモ



[37\. Sudoku Solver](https://leetcode.com/problems/sudoku-solver/)

数独を解いてくださいという問題。

## 最初にやってみたけどダメだった解き方

1. 縦の並び、横の並び、3×3の領域にある数字から、入る数字が一意に定まるマスを探す
2. あればそのマスを埋める
3. 空いているますがあれば1.に戻る

これは非常にバカな間違いで、数独においては必ずしもそうして数字が決められるわけではないのだった。

## 次に試した解き方

`fill`という関数を定義して、`fill(board, 0, 0)`を呼び出して全てのマスを埋める。
で、その`fill`は次のようになる。(TypeScript)

```typescript
function fill(board: string[][], x: number, y: number): boolean {
  // yが9ということは領域外===全てのマスを埋めることができたので成功
  if (y === 9) return true
  
  const nextX = x === 9 ? 0 : x
  const nextY = x === 9 ? y + 1 : y
  
  // 数字がすでに入っている場合
  if (board[y][x] !== '.') {
    // 次のマスに進む
    return fill(board, nextX, nextY)
  }
  
  // その場所に入れることができる全ての数字を列挙する
  for (const char of possibleChars(board, x, y)) {
    // 数字をそのマスに入れてみて次のマスに進み、そのまま最後のマスまで到達できたら成功
    board[y][x] = char
    if (fill(board, nextX, nextY)) return true
  }
  
  // どの数字もダメだった場合は、マスを空にして終了する
  board[y][x] = '.'
  return false
}

function possibleChars(board: string[][], x: number, y: number): Iterable<string> {
  // 省略
}
```

まあ要するにおける数字を手当たり次第に試していくというごく簡単なやり方であるが、
ダメな手を打つとその先で打つ手が無くなってしまうはずなので、意外とステップ数は爆発しないと思う。

だが、これを提出してみると再帰が深すぎてエラーになってしまった。
処理系がちょっと弱すぎないか...。
別の言語使えって話かもしれないが。

今のところLeetCodeは解ける問題は全部TypeScriptで解いているが、再帰が全然使えないので困っている。
(再帰を使わずにどうやって解くかというのを考えるのも楽しいけど。)

というわけで、基本的にはこのアルゴリズムで、再起を使わずにスタックを使って実装したものを提出したら合格した。

スタックのオブジェクトにIteratorを持たせておくことでループの状態をいい感じに保持できることに気づいた時は気持ちよかった。


LeetCode 37 Sudoku Solver


最近LeetCodeの問題を解いてみている。

アプリ作ったりするのに比べて純粋に正解を目指せばいいのである意味で気が楽だし、コードがそこまで長くないので短い時間でもやった感が出るのが良い。


LeetCodeを始めてみた


タイトル通り。
まあほとんど読まれていないと思うので単なる自己満足かもしれないが。

JavaScriptの[feed](https://github.com/jpmonette/feed)というパッケージを使ってフィードのXMLを作っている。
このライブラリは割と使いやすくて、`Feed`オブジェクトに適当に情報を追加するだけで、AtomなりRSS1/2なり好きなフォーマットで出力できる。

ライブラリがやってくれるので特に必須ではないけど、Atomフィードがどんなものか知るために、[Introduction to Atom](https://validator.w3.org/feed/docs/atom.html) というW3Cのドキュメントを覗いてみたりした。
これは[W3C Feed Validation Service](https://validator.w3.org/feed/)に付属するもので、自分でXMLを作る場合はこれで確認しながらやると良いかもしれない。

このサイトは、[以前にも書いた](/2021-01-04_starting)ように、Next.jsで書いてVercelでホストしている。
最初は1つのページとしてフィードを吐こうと思ったが、Next.jsでXMLをサーブする方法がよく分からなかったので、ビルド時に静的ファイルとして出力してみた。

最近使っているInoreaderでフィードを購読してみたら、日付が全部同じになってしまった。
これはInoreaderの問題なのか、フィード自体に問題があるのかよく分からない。


サイトにAtomフィードを付けてみた

## TL;DR

-   [[TypeScript]]で、ハッシュ関数と等値性を指定できる[[Map]]と[[Set]]を書いた。
-   APIは[[ECMAScript]]のそれらとほぼ同じになるようにした。
-   最初は[[Java]]のLinkedHashMapを移植しかけたけど、ライセンス的に問題があるかもしれないので少し違うものに置き換えた。
-   <https://github.com/odiak/map-and-set>で公開した。

***

先日、[[JavaScriptのSetはオブジェクトを入れづらい]]という話を書いたんだけど、その勢いでMapとSetを自分で実装してみることにした。

改めて書くと、やりたいことは、等値性とハッシュ関数を指定できるMapとSetを作ること。
APIはできるだけ[[ECMAScript]]のものと同じにしたい。

クラスの定義はこんな感じ。(コンストラクターの型定義だけ。それ以外のメソッドの型はESと同じ。)

```typescript
class Map<Key, Value> {
  constructor(
    iterable: Iterable<[Key, Value]>,
    {
      hash: (key: Key) => number,
      equal: (key1: Key, key2: Key) => boolean)
    }
  )
}

class Set<Value> {
  constructor(
    iterable: Iterable<Value>,
    {
      hash: (val: Value) => number,
      equal: (val1: Value, val2: Value) => boolean)
    }
  )
}
```

なお、ECMAScriptのと同じく、MapもSetも挿入順が維持されるようにしたい。

## JavaのHashMap, LinkedHashMapを移植してみる→断念

僕が知っている範囲だと、オープンソースの実装を参考にするならJavaのHashMapやLinkedHashMapがいいんじゃないか、と思って探してみた。

-   [jdk7u-jdk/HashMap.java at master · openjdk-mirror/jdk7u-jdk](https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/HashMap.java)
-   [jdk7u-jdk/LinkedHashMap.java at master · openjdk-mirror/jdk7u-jdk](https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/LinkedHashMap.java)

最初にHashMapを見て大まかに理解したあと、LinkedHashMapを見ると理解がスムーズだった。

APIは多少違うけど、これを移植すればいいんじゃね〜と思ってTypeScriptで同じようなものを書いてみた。
その時の実装が[これ](https://github.com/odiak/map-and-set/blob/7fe53da455e7a31552785f8a74e49368b100bc3c/src/map.ts)。

そのことをTwitterに書いた。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">とりあえず、JavaのLinkedHashMapを移植してMapを作った</p>&mdash; かいどう🐵 (@odiak_) <a href="https://twitter.com/odiak_/status/1357293417689088001?ref_src=twsrc%5Etfw">February 4, 2021</a></blockquote>

すると、JavaのソースはGPLなので別ライセンスのプロジェクトに移植するのはまずそう、というのを指摘してもらった。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">JavaのGPLコードの移植だとGPLにしないといけない気がする</p>&mdash; きしだൠ(K8S(Kishidades)) (@kis) <a href="https://twitter.com/kis/status/1357296380289552389?ref_src=twsrc%5Etfw">February 4, 2021</a></blockquote>

## V8の実装を参考にしてみる

APIをかなり変えて移植する場合、ライセンス的にどうなのかな？というのは気になったけど、念のため違う実装で置き換えることにした。
そこで見つけてきたのがこの記事。

[\[V8 Deep Dives\] Understanding Map Internals | by Andrey Pechkurov | ITNEXT](https://itnext.io/v8-deep-dives-understanding-map-internals-45eb94a183df)

V8のMapがどう実装されているかという話で、JavaのLinkedHashMapにも近いけど、Entryの順番を保持するための方法が若干違っている。
これを参考にして実装してみることにした。

C++の実装だと、効率化のために予め長さを決めた配列の上にEntryを並べているようだけど、TSではArrayの後ろにpushで追加していくようにした。
もう少し改善の余地はある気がするけど、まあいいや。

出来上がったのがこれ。 <https://github.com/odiak/map-and-set>

npmでも公開した。 <https://www.npmjs.com/package/map-and-set>

標準のMap/Setで満足できない人は、よかったら使ってみてください。

***

## 脱線コーナー

### Jestのはなし

今回は、[[Jest]]というテストのツールを初めて使ってみた。以前にChai+Mochaを使った気がするけど、Jestの方が設定が楽かなぁ？
いや、TypeScriptを使わないなら楽だと思うけど、TSを使うとトータルの手間はあまり変わらないかも。
ツール自体はよくできていると思う。

### JavaのLinkedHashMapと、V8のMapの違い

どちらも、挿入順が維持されるマップの実装。
[[ハッシュテーブル]]にEntryオブジェクトを連ねていく点は共通だけど、挿入順を維持するための仕組みが少し違う。

イメージ:\
![](https://i.kakeru.app/7681efcb1643e2d8c86613caf3f9feb1.svg)

#### JavaのLinkedHashMap

LinkedHashMapは、名前の通り、双方向リストを使っている。
Entryオブジェクト自体がリストのノードにもなっていて、前後への参照を持っている。

LinkedHashMapはheadという特殊なEntryを保持していて、そこを起点にしてそのほかのEntryが連なり、最後のEntryの後ろがheadに繋がる。

Entryを追加するときは、まずハッシュ表から出ている単方向リストの先頭にEntryを追加し、次にheadから始まる双方向リストの最後にEntryを追加する。

削除するときは、まずハッシュ表から出ている単方向リストからEntryを削除し、次に双方向リストからEntryを削除する。

双方向リストを、headを使って頭とお尻をつなげて持っておくことで扱いやすくしているのがなるほど〜と思った。(よくある実装なのかもしれないけど。)

TypeScriptで書くときは、headの扱いが型的に面倒なので、循環させずにheadとtailを持つことになるかな。

#### V8 Map

こちらは、dataTableというEntryの配列を持っており、長さはハッシュテーブルのサイズの2倍。
つまり、それより多くのEntryを入れたい場合はリハッシュせざるを得ない。

また、dataTableに実際に詰まっているEntryの数をnextSlotという変数に入れている。
ここまで聞くとArrayListっぽいなという気もするけど、Entryを削除する時の挙動が面白い。

Entryを追加するときは、まずハッシュテーブルから出ている単方向リストの先頭にEntryを追加して、dataTableのnextSlot番目にEntryを入れてnextSlotをインクリメントする。

Entryを削除するときは、単にEntryのkey,valueをnullで埋めてしまうだけ。
空になったEntryは、ハッシュテーブルを見るときやEntryを列挙するときには無視すればいいだけ。

挿入や削除を何回か行うと、dataTableがいっぱいになってしまう。
削除が行われた場合は、空のEntryもできる。
いっぱいになってしまった場合は、前述したようにリハッシュする。

この実装もなかなか面白いな〜と思った。

TypeScriptでこれを実装するにあたって、キーにnullも入れられるようにしたかったので、ひと工夫が必要だった。
といっても、EntryとEntryContainerという2つのオブジェクトを作り、EntryContainerがEntryを持ち、dataTableはEntryContainerの配列にする。
削除の時には、EntryContainerからEntryを取り除く(nullを入れる)というふうにした。


TypeScriptでMapとSetを書いてみた

[[JavaScript]]にはSetというクラス(?)があり、一意な値を含んだコレクションを表現できる。
もちろん、プリミティブな値もオブジェクトも入れる事ができる。

プリミティブな値は話が簡単だが、オブジェクトの場合はちと面倒くさい。
オブジェクトの同値関係を自分で定義する事ができないのである。

具体的には、Setに追加される値は`Object.is`で比較するのとほぼ同じ方法(もっと具体的にはsame-value-zero equality)で既存の値と比較される。
なので、例えば`[number, string]`のような型のタプルのSetを作っても、同じような値(例えば`[2, "bar"]`)を何度も追加する事ができてしまう。

どうするか。

## 自分でSetクラスを作る

これは一番確実かもしれない。

ただ、ちゃんと効率的に作るのはそれなりに大変だと思う。
面白そうなのでそのうちやってみたい。

というか、npmにそういうのないのかな？

パフォーマンスが悪くても良ければ、内部を配列にして、挿入するたびに同じ値が入っていないかを確かめるという雑な実装もありかもしれない。

## Mapを使う

これはかなり手抜き。
しかも前提条件があって、オブジェクト同士の比較が1つのプリミティブ値の比較になっていること。

例えば、`type Obj = {id: string, name: string, count: number}`というような型のオブジェクトを、
`id`さえ同じなら同値とみなすような場合。

この例を使うと、`const map = Map<string, Obj>()`を用意して、`map.set(obj.id, obj)`てな感じで値を挿入することで、
`id`が一意な`Obj`オブジェクトのコレクションが作れる。

## まとめ？

JavaScriptのSetオブジェクトが微妙に使いづらいので、なんとかする方法を考えてみた。

Setに関する[[ECMAScript]]の仕様も読んでみたいな〜。

あと、MDNの[JavaScriptの等価性に関するページ](https://developer.mozilla.org/ja/docs/Web/JavaScript/Equality_comparisons_and_sameness)が面白かった。(軽く眺めた程度だけど。)\
same-value-zero equalityについても今回そのページを見て初めて知った。


JavaScriptのSetはオブジェクトを入れづらい


2020 年は、いろいろあった。今更だけど、雑に振り返ってみようと思う。  
(本当に雑に書いてます。途中から書く気力がなくなってさらに適当になってきました。)

## ざっくりまとめ

- 子が 1 歳になった
- COVID19 が流行して自宅勤務に
- 仕事への悩み
- 子育て辛い
- 保育園に入れた
- Kakeru の開発
- 家を買うことになった
- まだオープンにはできない何か
- よく寝ましょう

## 子育て+在宅勤務が大変

2019 年の秋くらいからすでに子育てはまあまあ大変だった気がする。  
朝のある程度決まった時間に起こされてご飯を用意して食べさせたり、遊んであげたりするのがしんどかった。

2020 年、徐々に歩けるようになって活動範囲が広くなってきた。  
最初は 1 つの部屋でしか遊んでいなかったが、途中からベビーゲートを外して好きな場所で遊ばせるようになった。  
あちこち動き回るし、棚や机の上にあるものに手を伸ばしてくる危険な存在になった。

しかもそのタイミングで在宅勤務が始まった。

朝、ご飯を食べた後にだらだらと子供と遊んでいると、仕事を始めるタイミングを見失う。  
仕事を始めてしばらくすると今度はお昼ご飯なので、様子を見て僕も用意を手伝ったり食べさせたりする。  
そんな感じでなかなか集中できずストレスがたまった記憶がある。

その当時は少し広めのリビングに机を置いてそこで作業していたのだが、僕の机を別の部屋に移動してみることにした。  
納戸というかいろいろ物を置いている部屋で、エアコンもないし狭いのだが、仕事中に子供と距離を距離を取れるなら良いだろうと思った。  
結果的に、それはまあまあ良かった。ミーティングをする時にも気を使う必要がないし、何よりノイズがないので集中しやすい。

## 妻が仕事を始めて、子を保育園に入れる

春くらいから妻が仕事を始めることになった。  
以前勤めていた会社の仕事を、自宅で、かつ作業量は少なめで。

ただ、その時はまだ子を保育園に入れていなかったので、かなり大変だった。  
作業時間は子供のお昼寝中とか、寝た後とかになる。
その上に家事もやってくれていたし...。

そんな感じだったので、保育園に入れることを検討し始めた。
近所の小規模保育園に 1 つ空きがあったので、申し込んだところ入ることができた。  
両親とも働いている状態で申し込めたので良かったが、まだ仕事を探している段階の人はかなり大変だと思う。

入る前は見学に行ったり(見学に行かないとその園に申し込めない)、書類を書いたりし、
入園が決まってからはタオルやビニール袋などを用意して、服に名前を書き、
入ってからは慣らし保育で少しずつ時間を伸ばしていき、となかなか大変だった。  
働いたり仕事探したりしつつこれやるのなかなかハードでしょ。

とにかく、いろいろもっと楽にならないかな？と思った。
保育園で使うものとか、適当に向こうで用意して洗ったり管理したりしておいて欲しい。(要は金で)

でも保育園に入れたのはいろいろな点で良かった。1 つは夫婦 2 人ともに心の余裕が生まれたこと。  
仕事や家事もできるし、昼ごはんをゆっくり食べたりもできる。

もう 1 つは、子供にとってのこと。
家ではしない遊びを保育園ではするし、他の子と一緒に遊ぶことで良い刺激にもなっていたと思う。  
プライベートでは他の子と会うことはあまりなかったし、自宅では同じような遊びばかりになりがち。

だいぶ楽になったとはいえ、それでもやっぱり時間はない。  
どれくらい時間がないかというと、朝 9 時に保育園に送り出して、17:30 くらいに保育園から帰ってくるまでの間に 8 時間半しかない。  
帰ってからは家族でご飯を食べ、遊んで、風呂に入って、寝るのが遅くて 21:00 くらい。  
ほとんどの日は一緒に寝て一緒に起きるので、びっくりするくらい時間がない。

保育園に行っている間は楽だけど、送り出すためにちゃんと起きないといけないのは少しだるいところもある。  
ただ、そのおかげで生活リズムは改善されたと思う。  
少々遅れても保育園に送り出せる時間にはなんとか起きるし、送っていくのは僕の担当なので、その途中で陽を浴びて散歩もできる。
これは非常に良い変化だった。

## 仕事がだるい

在宅勤務が始まったくらいから、仕事がだるいなーと思うようになった。

原因は多分いろいろとあって、一つは前述した子育てへのストレスとか、あとは睡眠不足もあったと思う。  
子育てのストレスは保育園に行くようになって少し減ったし、秋くらいからかなり寝るようになったのでだいぶ障害は取り除けたと思う。

ただ、ひとつ言えたのは、やっていた仕事に興味を失っていたところである。

なんかだるいので、転職やあるいは社内の別の仕事を探すといったことにもあまり積極的になれず...。

今までやっていたのと少し方向性の違うことをやってみたり、別のプロジェクトの仕事を手伝ってみたりもしたので、その辺はよかった。

転職に関しては、若干行動はした。

まず、ビデオ通話でカジュアル面談みたいなのをいくつか受けてみた。  
まあ悪くない会社だなーと思ったことは何度かあったが、強い興味を感じたところはなかった。  
精神状態がよくなかったというのもあると思うが、オンラインで少し話しただけだと会社のことって全然分からないなと思った。

やっぱり、オフィスに行ったり飲みに行ったり(飲まなくても、食事だけでもいいと思うけど)しないとダメなんだろうか。

あと、ネットで見つけたとある会社がお試し入社的に仕事をさせてくれるようだったので、1 日 1 時間くらいなら時間割けるかなと思ってやってみた。  
最初はうまく行っていたが、僕のやる気がなくなってきてしまったのと、単純に時間がなくて終わった。(経緯は省略)

ただ、こういう仕組み自体はすごく良いんじゃないかなーと思った。
仕事の様子とか、Slack のやりとりとか見ているだけでも会社の雰囲気がだいぶ分かるしね。

この件で懲りて、睡眠を削って無理やり時間を作り出すのはもうやめることにした。  
それまでは別に削ってる感じはそこまで無かったんだけど、よく考えると無理しているなと気づいた。

2 時間ぴったりだけ作業して寝よう、とかができればいいんだけど、僕の場合はそれができない。  
ついだらだらと作業を続けたり、作業後に眠い目を擦りながらインターネットを徘徊してしまったりする。

普通に生活していても、子供を寝かせる頃には意外と疲れているので、子供と一緒に寝てしまうのが一番良いことに気付いてしまった。  
そんな感じで最大 10 時間くらい寝ている。
途中で起きてしまったり、一緒に寝付けなかったりで、必ずしも毎日たっぷり寝ているわけではないけど、以前よりはかなり寝ていると思う。

## Kakeru の開発

Twitter ではたまに言及していたけど、[Kakeru](https://about.kakeru.app/ja)という、共同編集できる手書きのホワイトボードのような Web アプリを作っていた。

去年を通してちまちまと開発していて、僕のちょっとしたモチベーションになっていた。

ただ、最近、意外と需要はないのかもしれないなーと思っている。
なぜなら僕自身があまり頻繁には使っていないから。

あと、メインとなるユーザーは、iPad+Apple Pencil を使う人なんだけど、その時点でかなり絞られてしまう。  
テキストで付箋的なのも貼れるようにしたら、PC でも iPad でも使えて良い感じになるかな〜？

そもそも、スマホばっかり使ってしまい、iPad を使うシーンが限られてしまう。
今のデスク環境(デスクのある部屋が寒すぎるので、食卓で仕事してる)もあるかもしれないけど...。

今年はスマホよりも iPad を使っていきたいなーと思うんだけど、子供がいるとそもそも時間がないという問題があり、Twitter などの無駄なネットサーフィンをせずに時間を捻り出す必要があるよな。

## 家を買うことになった

年末、急に家を買うことになった。

というのも、近所で新築の戸建てが売られていて、良かったのですぐ買うことにした。  
もともと、かなり前から、主に家の断熱性能が悪すぎるという理由で引越しを考えており、猫を飼ってるしなかなか良い部屋ないなーという感じだったので、スッと決めた。

住宅ローンや家に関する知識なども全然なく、場所(今の家も駅のそばで良い場所だし、そのすぐそばなので)と、値段と、間取りや設備(100 点ではないけど、それなりに良い)で決めた。

詳しくはまた書こうと思うが、今はローンの手続きなどをやっている。

## まだ書けないサムシング

ずっとやろうと思っていたことではあるが、少し前から動き始めていたことがある。
そのうちオープンにできると思う。

## その他

飲みにいく頻度は以前よりは減ったけど、それなりに飲みに行ったと思う。
でも、新しい人にはあまり会えなかったかも。

子供を保育園に行かせてるので、ランチに妻と 2 人で時間を過ごせるようになったのはかなり良い変化だったな〜〜。
本当は夜にも出かけたいんだけど...。

今年もあまり新しい出会いはないかもしれないけど、程よい頻度で美味しいものやお酒を楽しみにいきたい。

あ、別の記事にも書いたけど、Nintendo Switch を買ったんだった。フィットボクシングが結構楽しい。  
散歩したりフィットボクシングしたり、以前よりは少し動くようになったかもしれない。もう少し頻度を上げていきたいけど。

## おわりに

COVID19 の影響も、そうでないものも合わせて、なにかと変化の年だった気がする。

去年得られた一番の教訓は、「よく寝ろ」かな。

補足しておくと、お酒を飲みすぎるとよく眠れなくなる。


いまさら2020年の話をする


買い物自慢です。
順番は単に思い出した順です。

## AirPods Pro

AirPods は前から使っていたんだけど、電池が消耗してきたし Pro が良さそうだから買ってみたところ、めっちゃよかった。

外音取り込みモードを使うと、耳に深く差し込んでいるのに以前の AirPods や EarPods のような抜け感のある聞こえ方になるし、
ノイズキャンセリングを有効にするとしっかり遮音してくれてうるさい場所でも快適になる。  
飛行機とか新幹線とかに乗るときに耳栓がわりに使っても良いと思う。

つけ心地は、カナル型が苦手な自分でも割と快適だった。
前の AirPods の方が耳が疲れないけど、一方で Pro は耳から外れにくいという良さがある。  
ただし、耳が汚れていると(特にウェットな耳垢の人)耳から取れやすくなるので、いつもよりもこまめに耳とイヤーピースを掃除するようになったと思う。

肝心の音質だけど、僕はそれなりに満足だった。もちろんちゃんとしたスピーカーやヘッドフォンで聞くと「いいな〜」と思うけど、これで音楽を聴いていても特に不満はない。

ワイヤレス充電にも対応していて、後で言及するワイヤレス充電器を買ってからは、そこに置いて充電することが多くなった。

## LG の 4K ディスプレイ

27UK850-W

4K で 27 インチのディスプレイで、USB Type-C(Thunderbolt)でラップトップを接続して給電もできる。会社のオフィスにも同じものがあり、まるで会社から持って帰ってきたような気分に。  
というか、4K で 27 インチで USB Type-C で接続して給電もできて、それほど高くないものを探すと自動的にこれ(あるいはこれのより新しいモデル)になってしまう。

4K は、良いです。

仕事でもプライベートでも使っていて、2 台の MacBook Pro 間でケーブルを差し替えるだけで環境を切り替えることができる。  
ただし、今は部屋の都合で一旦休眠中。

## MacBook Pro

ここ数年の間に Windows を使ってみたり Ubuntu を使ってみたりしたけど、やっぱり Mac がいいなということで改めて買った。
普通に良い。

メモリを 32GB 摘んだのでかなり安心感が高いのと、ESC キーが物理キーになっているのが良い。(個人的には、タッチバーは嫌いではない。)

## Galaxy Note20 Ultra 5G

スマホが古くなってきたので奮発して良いのを買うかーと思ったのと、ペンがついていて画面が大きいので Kakeru を使ってみるかな？と思って買った。

とにかく大きいので、少し扱いに困る。具体的には、手やポケットから落ちやすいのと、ポケットが小さいと厳しい。  
その代わり、画面は大きくてきれいだし、カメラの性能が素晴らしい。防水なので風呂に持って行ったり洗ったりもできる。

画面のエッジが狭いのは、良いんだろうと思っていたが、微妙なところもあった。  
1 つは、手が端の方に当たって誤操作してしまうこと。これは画面の端がカーブしているのもある。画面の端は普通に角張っていた方が良いと思う。
もう 1 つは、スマホスタンドなどに載せたときに、端の方が少し隠れてしまいがちなこと。

あ、そういえばこの端末には、顔認証と指紋認証が両方ついているんだった。  
指紋認証は画面内にある。反応はあまり良くない(というか正確な位置に触れるのが難しい)けど、背面にセンサーがあるよりは良いと思う。  
顔認証も便利であるが、マスクをしていたりもするので両方ついているのはかなりよかった。

ワイヤレス充電にも対応していて、後述の充電器が役に立っている。とはいえ、ケーブルを刺した方が早く充電できるのと、ワイヤレス充電器に AirPods Pro や妻のスマホが置いてあることもあり、ケーブルで充電することが多い。

## iPad Pro

欲しいなとは思いつつ、iPad Air もいいしなーとか古い iPad Pro があるしなーとか思って買えなかったが、年末に思い切って買ってしまった。後悔はしていない。

USB Type-C で充電できる(これで僕の普段使いのデバイスはほとんど Type-C で充電できるようになった)し、Apple Pencil もくっつくし、画面は 120Hz だ。素晴らしい。  
Kakeru をしばらく使ってバグを見つけて直したりもした。

今回、iPad には SNS のアプリを一切入れないことにしてみた。おかげで、これで本を読んだり何かを描いたりする時は集中できることが多い気がする。

## MiBand 5

Fitbit Alta HR のバンドが切れて、その上もう純正バンドが売っていない(しかも製品自体も販売終了)のと、Fitbit のアプリと通信するのにやたらと時間がかかるので、Xiaomi のバンドに買い換えてみた。

概ねできることは Fitbit と同じで、大きな違いはディスプレイがカラーになって少し広くなったことくらい。睡眠トラッキングは Fitbit の方が少し精度が良いかも？という気がするくらい。

## Keychron K1

https://www.keychron.com/products/keychron-k1-wireless-mechanical-keyboard

2 台のラップトップをクラムシェルで使う都合上、ワイヤレスで複数デバイスに接続できるキーボードが必要じゃない？ということで買ったやつ。

薄型のメカニカルスイッチは程よい押し心地で良い感じ。デバイスの切り替えもかなり便利で、有線でも接続できるのが良い。  
ただ、チルト機能がついていないのと、Enter キーの右が長いのがちょっと不満。(トラックパッドまでが遠いため。)

チルト機能は、裏に段ボール貼ってそれっぽくしたけど...。

買って少ししてから、K3 が発表されたので、Kickstarter 経由で注文してみた。発送は始まっているみたいだが、まだ僕には届いていない。楽しみである。

ところで、2 台のラップトップ切り替え問題に関しては、最終的にはいろいろなデバイスを有線で接続するのが良いという結論に至ってしまった。  
そうなると、キーボードは Magic Keyboard で十分だったのではという心の声もある...。薄いメカニカルも良いですけどね...。

## ワイヤレス充電器

Galaxy Note に AirPods Pro に、ワイヤレスで充電できるデバイスが増えてきたので買ってみた。

これは良い。デバイスを置くだけでケーブルを刺さずに充電できる、ただそれだけです。

## Nintendo Switch

家で運動をするのに FitBoxing やリングフィットアドベンチャーをやってみたいと思っていた。  
ところが、スイッチの本体が品薄だったためメルカリで買うか悩み続けていたところ、年末になってようやく Amazon で定価で購入できるようになったのでポチってしまった。

まだリングフィットアドベンチャーはほとんどやっていないが、FitBoxing は週に数回やっている。なかなか楽しい。

## Logicool の Web カメラ

Logicool StreamCam (C980GR)  
https://www.logicool.co.jp/ja-jp/product/streamcam

MacBook Pro をクラムシェルにしてディスプレイに繋ぐようになったので、カメラが使えなくて困った！ということで買った。  
[r7kamura さんが紹介していた](https://r7kamura.com/articles/2020-09-23-web-camera)ので試してみた。
今年は Web カメラが品薄になりがちだったけど、これは買えた。

お値段がお高いだけあって画質はかなり良い。
付属のソフトウェアでいろいろ設定をいじれるので、配信とかする人は良いんだろうなーと思う。
今のところ、ビデオ会議で自分の顔を写すのにしか使ってないが。

## FontAwesome Pro

Kakeru で使うために買った。アイコンを自分で作ってみようかなーとも思ったけど、コード書く時間が減るのでお金で解決することにした。

といっても、今のところ Pro のアイコンは 1 つしか使っていない。
今後なんかアイコンが欲しくなったときに選択肢が増えるのでまあいいか。買い切りだし。

## Raspberry Pi

Pi 3 Model B

なんとなく、音楽を再生するやつにしてみようかと思って買った。  
AirPlay サーバーと Spotify connect のサーバーが動いているけど、最近は Spotify connect ばかり使っている。

AirPlay の方は shairport-sync、Spotify は spotifyd というソフトウェア。

Android から ChromeCast 的なやつで再生したいなーとか、Bluetooth 経由で再生できないかな？とかいろいろ試したけど、諦めた。(Bluetooth は頑張ればなんとかなりそうだが、かなり辛そう。USB のオーディオデバイスを扱うだけで精一杯...)  
また、shairport-sync と spotifyd でオーディオデバイスの奪い合いをしてしまうようで、切り替えながら使うのは少しストレスだった。それもあって Spotify しか使っていない。

spotifyd は最初は手でプロセス立ち上げていたけど、たまに落ちるので systemd のサービスにした。  
それでも調子が悪い時がたまにあり、Raspberry Pi の電源を切って再度入れるという荒技で対処している。

Spotify で音楽をかけるのが楽になったのでかなり快適。

## Wi-Fi ルーター

NEC Aterm PA-WG2600HP3

今まで使っていた Apple 製のルーター(モデルは忘れた)がかなり遅いような気がしたので、新しいのを買ってみた。  
かなり速くなったと思う。

買ってから分かったことだけど、周りに 2.4GHz の電波が飛びすぎていて、2.4GHz だと速く通信できないことが多いっぽい。なので、5GHz を積極的に使うことにした。
(Apple のルーターも 5GHz に対応していたはずなんだが、...)

IPv6 に対応しているので、IPoE の設定をしてさらに高速化するぞーと意気込んでいたが、どうやらうちのプロバイダーではいろいろと手続きが面倒臭そうで挫折した。  
いろいろ調べた結果、スマホの回線でもお世話になっている IIJ の光コラボに乗り換えると無料で IPv6 も使えるし、割引も効き、支払いもまとめられて良さそうというところまで分かった。  
今年はそれを進めたい...。

---

去年も無駄にたくさんものを買ってしまった。
今年はあまり大きな買い物はしないような気がするけど、1 つ挙げるとすれば良いスピーカーを買いたい。


2020年に買ったものハイライト


最近個人ブログ的なものに回帰する人たちがちらほらと見られるので、自分も遊びがてらにサイトを作り直しつつ、ブログっぽいものを作ってみました。

データは GitHub に Markdown で置いておき、Next.js で配信するといった感じです。  
インフラは Vercel を使ってみています。
Next.js をちゃんと使ってみるのと、Web の勉強や実験の場所にするという目的もあります。

やりたいことはこんな感じです:

- OGP とか設定してみる
- サイトのパフォーマンスを測ったりそれをもとに改善したりしてみる
- Markdown を拡張して Scrapbox 的な記法を導入し、ページ間のつながりを表現してみる
  - タグ的な概念を導入せずにタグ的な機能を実現したい
  - 関連記事を表示したい
  - 要するに、Scrapbox の機能の一部を自分で実装してみたい

週に 1 回くらいは何か書いていきたいと思います。


個人サイト兼ブログのようなものを再始動させてみます

[[Kakeru]]にCDNを導入した記録。
結論を先に書いておくと、CDNを断念してNginxのキャッシュ機能を使うことになった。

***

## 2022-03-13

Fastlyを設定して、i.kakeru.appの画像をFastly経由で配信するようにした。
今まではAppEngineから直接画像を配信していたんだけど、リクエストが多いから料金が高くなるし、キャッシュされないから少し遅いなどの問題があった。

次はもう少しキャッシュの時間を長くして、更新されたらパージする運用にしていきたい。

設定しただけなんだけど、やたらと時間がかかった。
エラーが出て、正しいレスポンスが返ってこないのである。
結果的にはTLS関連の設定が間違っていたんだけど、何が問題なのか分からずに色々な設定を延々といじっていた。

## 2022-03-14

絵が更新されたらFastlyのキャッシュをパージするサーバーを作っていた。
絵を描いている最中は高頻度で更新されるので、変更のたびに処理するのではなく、
一定時間おきにまとめて処理したい。
そこで、Node.jsでリクエストをdebounceするようなやつを作った。

Kakeruの画像URLは、デフォルトのSVG以外はほとんど使っている人はいないと思うけど、
実はPNGやサイズの調整など色々な裏オプションがある。
というわけで、一つの絵に対して複数の画像が紐づいている。
そういうときに、全部まとめてキャッシュをパージするにはどうすればいい？
→Surrogate-Keyというヘッダを使うらしい。
[サロゲートキーの使用方法 | Fastly ヘルプガイド](https://docs.fastly.com/ja/guides/working-with-surrogate-keys)

Surrogate-Keyヘッダを返すようにして、キー単位でパージを試してみた。
ところが、なんかキャッシュがおかしい。
どうやら、Last-ModifiedまたはEtagを返していないのが問題っぽい。
あと、stale-while-revalidateなどの指定も必要そう。
[ソフトパージ | Fastly ヘルプガイド](https://docs.fastly.com/ja/guides/soft-purges)
[Cache-Control - HTTP | MDN](https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Cache-Control)

## 2022-03-16

まあ色々やっていたんですが、Fastlyの料金表を料金表を改めて見てみたら、最低金額が$50じゃないですか。
ちょっとナメてました。出直します。

普通にVM立てて、その中でキャッシュの仕組みを作りますかのぅ。
Redisに詰めてもいいかなと思ったんだけど、メモリ分しか使えないのでどうかな。
ストレージにキャッシュした方が多少遅くても容量を詰め込めるので良い気がする。

調べていたら、Nginxのキャッシュを使うのが手軽で良さそう。
Cache-Controlヘッダーを見てキャッシュしてくれるし、stale-while-revalidateとproxy\_cache\_background\_updateを組み合わせるといい感じに裏でキャッシュを更新してくれる。

問題はパージですな。キャッシュのファイルを読んで、先頭のヘッダー部分を読み飛ばすとプレーンテキストでレスポンスが入っている。

    > buffer.slice(337).toString('utf-8')
    'KEY: http://127.0.0.1:5000/foo/bar\n' +
      'HTTP/1.1 200 OK\r\n' +
      'X-Powered-By: Express\r\n' +
      'cache-control: max-age=30, stale-while-revalidate=3600\r\n' +
      'Date: Wed, 16 Mar 2022 15:31:40 GMT\r\n' +
      'Connection: close\r\n' +
      '\r\n' +
      'hello, bar, 5'

ただ、ソフトパージ的なことができない。

が、revalidateを使えば良さそう。
(キャッシュ時間を短くして、last-modifiedを見て計算を省略すれば比較的コストを抑えてキャッシュを新鮮にできるはず、という)

https://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html

うーん、難しい。

## 2022-03-19

ソフトパージっぽいことができた。
色々試した結果だけど、キャッシュファイルの[ヘッダー部分](https://github.com/nginx/nginx/blob/828fb94e1dbe1c433edd39147ba085c4622c99ed/src/http/ngx_http_cache.h#L128-L144)をこんな感じでいじると良い

-   valid\_secは現在時刻のタイムスタンプ -1
    -   valid\_sec < now かつ valid\_sec + stale-while-revalidate > now な条件を満たせばキャッシュが更新されることがソースを読んで分かった
-   last\_modifiedはゼロ
    -   last\_modifiedが変わらないと、キャッシュの更新処理が走ってもキャッシュが上書きされない場合があるため (コンテンツは更新されているが、オリジンの返すlast-modifiedがまだ変わっていないというレアケースだけど)

ちなみに、キャッシュファイルの変更には[njs](https://nginx.org/en/docs/njs/)というNginx組み込みのJavaScriptの処理系を使ってみた。

    js_import purger.js;

    server {
        server_name localhost;
        listen 9000;

        location / {
            js_content purger.handler;
        }
    }

Nginxの設定にこんな感じで書いておいて、内側からリクエストを受け付けてキャッシュをstaleな状態にすることができた。
purge.jsはGistにメモとして残しておく。
https://gist.github.com/odiak/4694f85783a057d812f80ea537e4dfb7


KakeruにCDNを導入するぜー

共同編集ができるオンラインホワイトボードのWebアプリです。

https://about.kakeru.app/ja/


Kakeru

[[Google DriveとVS Codeでノートをとる話]]に関連して、
ノートをとるためのVSCodeの設定について書いてみる。

```json
{
    // 自動保存
    "files.autoSave": "afterDelay",

    // ファイルのソートを更新日順に
    "explorer.sortOrder": "modified",

    // Markdownの改行設定
    "markdown.preview.breaks": true,

    // テーマは新しいハイコントラストのやつを使ってみている
    "workbench.colorTheme": "Light High Contrast",
    // アイコンテーマはシンプルなやつ
    "workbench.iconTheme": "vs-minimal",
    // 色のカスタマイズ (ノートのウインドウを他のワークスペースと見分けやすくするため)
    "workbench.colorCustomizations": {
        "statusBar.background": "#136e07",
        "statusBar.foreground": "#ffffff"
    },

    // 製作中のWiki機能拡張を有効にする
    "vscode-wiki.enabled": true,

    // Google Drive上のディレクトリなので、ゴミ箱を無効にしておく
    "files.enableTrash": false,

    // 行番号は非表示
    "editor.lineNumbers": "off",
    // インデントレベルのガイドも非表示
    "editor.guides.indentation": false,
    // ホワイトスペースは末尾だけ表示
    "editor.renderWhitespace": "trailing"
}
```

見た目はこんな感じ
[![Imgur](https://i.imgur.com/ws2xxDIh.png)](https://imgur.com/ws2xxDI)


MarkdownノートのためのVSCodeの設定

去年(2021年)の秋から、サワードウというパン種を使ってパンを焼いている。

[サワードウ - Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%B5%E3%83%AF%E3%83%BC%E3%83%89%E3%82%A6)

昔から言葉は知っていたけど、特に興味はなくて食べたこともなかった。
で、久しぶりにその言葉を見たのがこの投稿であった。
[サワードウは育成ゲーム / jmuk - Message Passing](https://messagepassing.github.io/017-food/04-jmuk/)

なんか面白そう、ということでWebで調べて、スターター（パン種）を作ってみることにした。
ちなみにパン作り自体は、かなり前に2・3回やったことがあった。あと、昔に母がパンを作っていたのを横で見ていた。

- [①サワードゥスターターの起こし方 - 粉と水を混ぜる、これだけ！ | ＊３６５日＊おいしいものだけ](https://slowlifefantasy.com/2018/08/sourdoughstarter1/)
- [小麦粉と水だけで、ずっと使えるパンの種「サワードゥ（ルヴァン種）」をつくる｜はじめてのサワードゥ ブレッド](https://tennenseikatsu.jp/_ct/17466126)

あとで、本も買った。
[はじめてのサワードゥ ブレッド 粉と水だけの自家製酵母で作る | 真藤 舞衣子 |本 | 通販 | Amazon](https://amzn.to/3JPTdmG)

まずは小麦粉を水で練って放置し、毎日小麦粉と水を足すことでスターターを育てていく。
最初の頃は、途中でだめになって作り直したりもした。

いい感じに育ってきて、パンを作ってみるものの、本に載っている写真ほど膨らまなくてしょんぼりする。
でもまあ美味しい。

本に載っている全粒粉のサワードウのパンを、全粒粉だけを使って作っていたんだけど、よく見たら全粒粉を使うのはスターターだけだった。
それは膨らまないわ。

粉の比率を変えたら少しは膨らむようになった。

ほとんど買った1冊の本だけを見て作っているので他の作り方を知らないんだけど、こねる時間がほとんどないので、作るのは結構楽。
普通のパンの作り方を見ると、工程が多すぎてめっちゃ大変そう。

少し前、スターターをしばらく冷蔵庫で放置していたらかなり弱ってしまった。
手っ取り早く復活させるために、ドライイーストを加えるという超反則技をキメてしまった。
結果的に、サワードウの風味は残しつつ、ふわふわのパンが焼き上がった。
僕は何をやっているんだ？という感じもするけど、美味しいのでよしとする。

ところで、Twitterを見ていると、サワードウあるいはそれっぽいハード系のパンを焼いている人をちらほら見かける。
他の人の話も聞いて(or 読んで)みたい。

---

## 写真コーナー

### 最初の頃のスターターの様子

![スターター1](https://i.imgur.com/b28wVkuh.jpg)
![スターター2](https://i.imgur.com/F9G2zXwh.jpg)
![スターター3](https://i.imgur.com/kEGxkYzh.jpg)

### 最初の頃の焼き上がり

![Imgur](https://i.imgur.com/W1mQwhlh.jpg)
![Imgur](https://i.imgur.com/nBj50a5h.jpg)
![Imgur](https://i.imgur.com/CukTURBh.jpg)

### 最近焼いた、イースト混ぜたバージョンの1回目

![Imgur](https://i.imgur.com/YDNrO9Vh.jpg)
![Imgur](https://i.imgur.com/bbRqfNTh.jpg)

### イースト混ぜたバージョン2回目

![Imgur](https://i.imgur.com/Xp7UiS8h.jpg)

### 作っている様子

スターターと水などを合わせたところ。これから混ぜる
![Imgur](https://i.imgur.com/Ijoy5OZh.jpg)

小麦粉を加えて混ぜてしばらく置く
![Imgur](https://i.imgur.com/W5GwIhyh.jpg)

容器に入れて冷蔵庫で寝かせる前
![Imgur](https://i.imgur.com/pX97wBkh.jpg)

成形して2次発酵させて、焼く前
![Imgur](https://i.imgur.com/i5slBlzh.jpg)
