
Type Challenge の [IsNever](https://github.com/type-challenges/type-challenges/blob/main/questions/01042-medium-isnever/README.md) をやっていたときの学びのメモ。

IsNever はＴを渡した時にそのＴが never 型か否かを判定し、never 型であれば true を、そうでなければ false を返すという問題。

ぱっと考えると以下のように実装すればよさそうにも思える。

が、(難易度が medium なので当然といえば当然なのだが)これだと上手くいかない。

```typescript
type IsNever<T> = T extends never ? true : false;

type A = IsNever<never>;
// => type A = never;
```

## Distributive Conditional Types とは

これは期待される動作らしい。

以下の Issue にも解説がある。

<https://github.com/microsoft/TypeScript/issues/31751#issuecomment-498526919>

Conditional Types が Generic type に適用されるとき、それは Distributive Conditional Types と呼ばれるになるらしい。

公式ドキュメントには以下に記載されている。

<https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#distributive-conditional-types>

> When conditional types act on a generic type, they become distributive when given a union type.

つまり、以下のような動作になる。(公式の例を拝借)

```typescript
type ToArray<Type> = Type extends any ? Type[] : never;

type Foo = ToArray<string | number>;
// => type Foo = string[] | number[] のようになる
// (type Foo = (string | number)[] ではない)
```

また、never は空の Union type として定義されているらしい。

これは以下のように never と他の型 の union をつくると never 型が消えてしまうことからも、確かにそれっぽい挙動をしている。

```typescript
type Bar = string | never;
// => type Bar = stringとなる
// => type Bar = neverなどにはならない
```

この前提をもとに、IsNever の挙動を見る。

IsNever に never が代入された場合、never は空の union で分配する中身がないため never として判定される、ということのよう。(多分)

## IsNever の実装

Distributive Conditional Types の挙動を避ける方法もあり、それは`[]`で extends のオペランドを囲えばよい。

つまり、IsNever は以下のように実装すると想定通りの挙動になる。

```typescript
type IsNever<T> = [T] extends [never] ? true : false;

type A = IsNever<never>;
// => type A = true;
```


Type ChallengeのIsNeverをみる


## Zig 言語での開発

本当は去年もっと Zig での開発をしたかったが、暇と心の余裕がなさすぎてできなかった。

今年こそは Zig 言語を使った開発をもっと行いたい。

自分で Zig を使ってなにか開発するのは勿論やりたいが、Zig 言語自体や大きいプロジェクト(Bun など？)へのコントリビュートもしたい。

## 大学に通う

CS を学ぶべく放送大学に通うための準備を進めている。このまま行けば今年の 4 月から通えるはず。

自分は文系上がりのプログラマで、CS を体系的に学ぶことなくここまで来てしまったので、大学に通って知識をつけていきたい。

また、数学には苦手意識があり、これまで学びなおしに何回も失敗してきているので、この機会になんとか克服したい。

あと学びなおしという目的のほかに、CS の学位をとるという目的もある。

残念ながら放送大学だと教養の学位しかとることができないが、学位授与機構というものを利用することで情報の学位を取れないかと考えている。

<https://www.niad.ac.jp/>

## フロントエンド開発

これまでフロントエンドは敬遠してきたのだが、去年ガッツリと業務で携わった結果楽しかったので、もっとやっていきたい気持ちになっている。

今のところ React をメインで書いているが、別に React にこだわっているわけでもないのでなんでもやってみたい。

あと、マークアップやアクセシビリティの重要性も実感したのでそのあたりの知識もつけていきたい。


2023年 やりたいこと


ZigでJSONパーサーを書いたみた。

<https://github.com/ytakhs/zig-json-parser>

といっても、[RFC](https://www.rfc-editor.org/info/rfc8259)の通りに実装したわけではなく雰囲気で実装したものなので、真の意味でのJSONパーサーとは言えないかもしれない。

特に文字列部分はエスケープ処理などを行ってなかったりと結構処理を端折ってるので、これはそのうち対応したい気持ちはある。

実は今年の2月に一度ZigでJSONパーサーを書いてみてたのだが、テスト中に発生するメモリリーク周りでハマって上手く直すことができず、放置していた。

<https://github.com/ytakhs/json-parser-zig>

(リポジトリの名前が紛らわしいが、消すのももったいないので戒めに残してある)

## 実装に関して

パーサー実装素人ながら結構シンプルに実装できた気はしている。

以前の実装では字句解析と構文解析を別々に行っていたが、今回は特に分けずに行った。JSONパーサーくらいの簡単なものなら分ける必要がなかった。

また、細かい話だと、Zigではwhile文で他の言語のfor文のように後処理を追加できるので、それを使ってみた。

具体的には以下の`end += 1`の部分。

<https://github.com/ytakhs/zig-json-parser/blob/51f7246518b872da64afc8525691a58dd3dd4bc4/src/main.zig#L117-L121>


```zig
while (self.buf[end] != '"') : (end += 1) {
    if (end >= self.buf.len) {
        return Error.ParserError;
    }
}
```

今回使ってはみたものの、他の言語にはない独特な文法な気がしていて、わかりにくい気もしているが、自分がまだZigになれてないだけかもしれない。


ZigでJSONパーサーを書いた


<https://www.typescriptlang.org/docs/handbook/2/mapped-types.html#mapping-modifiers>

```ts
type Foo {
  readonly bar: string;
  baz?: number;
}
```

modifierとは上記でいう、`readonly`や`?`。

これらは`+`と`-`を使うことで、型に付与したり、削除したりできる。

(尤も、`+`に関しては特に指定が場合に自動付与されているため、明示的に使うのはもっぱら`-`の方かと思う。)

例えば強制的にmodifierを消す型は以下のようになる。


```ts
type Foo = {
  readonly bar: string;
  baz?: number;
}

type RemoveReadonly<T> = {
  -readonly [P in keyof T]: T[P];
}
type WritableFoo = RemoveReadonly<Foo>;

type RemoveOptional<T> = {
  [P in keyof T]-?: T[P];
}
type RequiredFoo = RemoveOptional<Foo>
```

[Playgroundでの実行結果](https://www.typescriptlang.org/play?ssl=14&ssc=1&pln=14&pc=39#code/C4TwDgpgBAYg9nKBeKBvAUFKAnCBDAEzgDsAbEKAIz2wC4oBnYbAS2IHMBuTKvALwD89YgFcAtpQjZuAX3TpQkKACUIYuADcIqwiXIAeACoA+ZGh4BaXLrIUA2gAUobKAGsIIOADMohgLr0ho5+sgrg0ADqrMB4lKQQ8IgoqupaOkS2+onG3GFKKZoQAPJgwCwkeKRGpigYWI7OxG4e3r5+FkK+waGK0KoAjiIsuASJZgVaJWUVVdlAA)


[TypeScript]型のmodifierを操作する


## 経緯

Remixのチュートリアルを眺めていたら、`Awaited<ReturnType<typeof getPosts>>`という型定義が出てきて気になったので調べた。

https://remix.run/docs/en/v1/tutorials/blog#a-little-refactoring

## Awaited型とは

TypeScript4.5から入ったAwaited型

<https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-5.html#the-awaited-type-and-promise-improvements>

導入されたPRは以下。

<https://github.com/microsoft/TypeScript/pull/45350>

この型ではネストしたPromiseを再帰的に評価した結果の型として表現できる。

※以下のコードは上記リリースノートのURLから抜粋

```typescript
// A = string
type A = Awaited<Promise<string>>;
// B = number
type B = Awaited<Promise<Promise<number>>>;
// C = boolean | number
type C = Awaited<boolean | Promise<number>>;
```

これにより、Promise.allなどの型定義が便利になるようだ。

Promise.resolveの型は`resolve<T>(value: T | PromiseLike<T>): Promise<T>`みたいな形になっており、TまたはPromiseLikeを受け取れる。

つまり、PromiseをラップしたPromiseは以下のような型になる。

```ts
type Foo = Promise<number | PromiseLike<number>>;
const foo: Foo = new Promise((r1) => r1(new Promise((r2) => r2(1))));
```

これを前提においた上で以下のような関数を定義を考える。

```ts
type Foo = Promise<number | PromiseLike<number>>;

async function foo(): Promise<[number]> {
  const foo: Foo = new Promise((r1) => r1(new Promise((r2) => r2(1))));

  return await Promise.all([foo]);
}
```

4.4以前だと、Promise.allにAwaitedがなかったため、`await Promise.all([foo])`の型が、`[number | PromiseLike<number>]`になってしまい、エラーになってしまう。

[TypeScript Playgroundで試した結果(4.4.4)](https://www.typescriptlang.org/play?ts=4.4.4#code/C4TwDgpgBAYg9nKBeKAFATnAtgSwM4QA8AdgK5YBGE6UAPmprgQDI4DWRZl1AfDwNwAoQQEM8IYgGMoAM1JTgOOMVkIAFAEoAXA2z4iAbS5V0AXR5QA3oKhRJyvMFVwd8RCmIQA7rqYQ1augAjBrIFsFqnj4YegQB6ABMoUjhCWohGplCNlDoEMCk6CoiXiI4TjF+AHQiADa1agYyCKYaQgC+gkA)

一方、4.5以上だとPromise.allにAwaitedが導入されているため、`Promise<[number]>`として評価され通るようになる、ということらしい。

[TypeScript Playgroundで試した結果(4.5.5)](https://www.typescriptlang.org/play?ts=4.5.5#code/C4TwDgpgBAYg9nKBeKAFATnAtgSwM4QA8AdgK5YBGE6UAPmprgQDI4DWRZl1AfDwNwAoQQEM8IYgGMoAM1JTgOOMVkIAFAEoAXA2z4iAbS5V0AXR5QA3oKhRJyvMFVwd8RCmIQA7rqYQ1augAjBrIFsFqnj4YegQB6ABMoUjhCWohGplCNlDoEMCk6CoiXiI4TjF+AHQiADa1agYyCKYaQgC+gkA)

## ReturnTypeとは

以下のドキュメントが全てではあるが、関数型の返り値を取得するUtility Types。

<https://www.typescriptlang.org/docs/handbook/utility-types.html#returntypetype>

`typeof`と併用することで、関数の実体から型を抽出して使うこともできる。

<https://www.typescriptlang.org/docs/handbook/2/typeof-types.html>

```typescript
function foo(): string {
  return "foo";
}

// type Foo = string;
type Foo = ReturnType<typeof foo>;
// type Bar = string;
type Bar = ReturnType<() => string>;
```


TypeScriptのAwaited, ReturnTypeの挙動について調べた

[TypeScript]AwaitedとReturnTypeを調べたメモ


## 技術

- ブログをS3 + CloudfrontからCloudflare Pagesに移行した
  - [Cloudflare Pagesに移行した](/entries/2022-04-11/migrate-to-cloudflare-pages/)
- JavaScriptのPromiseの仕組みに興味を持って調べてた
  - <https://zenn.dev/estra/articles/js-async-programming-roadmap>
  - <https://zenn.dev/estra/books/js-async-promise-chain-event-loop>
  - <https://zenn.dev/mizchi/articles/understanding-promise-by-ts-eventloop>
- QUIC周りを追いかけ始めた
  - <https://eng-blog.iij.ad.jp/archives/10039>
- ZiglangのParser周りのコードを読んでいる
  - Zigでパーサーを書きたいので参考にしている

## 書いた記事

結構書いた。

- [March 2022](/entries/2022-04-03/monthly-report/)
- [k8sのlabelsが色々ある件](/entries/2022-04-08/k8s-labels/)
- [k8sのStatefulSet](/entries/2022-04-08/k8s-statefulset/)
- [Web Linking](/entries/2022-04-08/web-linking/)
- [Rust 2024に向けてのロードマップを読んだ](/entries/2022-04-09/rust-2024-roadmap/)
- [Atom1.0のフィードに対応した](/entries/2022-04-11/atom-feed/)
- [Cloudflare Pagesに移行した](/entries/2022-04-11/migrate-to-cloudflare-pages/)
- [Ziglangのパッケージマネージャ](/entries/2022-04-17/zig-package-manager/)

## 本

- 読了
  - [プロを目指す人のためのTypeScript入門 安全なコードの書き方から高度な型の使い方まで](https://gihyo.jp/book/2022/978-4-297-12747-3)
    - 最近仕事でもプライベートでもTypeScriptにふれる機会が多くなったので、改めて理解を深めたいという動機で読み始めた。
    - TypeScriptの解説だけでなくJavaScriptの解説もあり、知らない機能も知ることができて良かった
    - RustのResult, Optionみたいなものを表現するpackageを復習がてら作ってみても良さそうと思っている
- 途中
  - [プロフェッショナルSSL/TLS](https://www.lambdanote.com/products/tls)
  - プロトコル周りに最近興味があるので読み勧めている
  - そのうちQUICとかにも進出したい

## 所感

- 何かしらに強みを持ちたいなと思っており、当面プロトコル周りを探ってみる予定
- ZigでHCLのパーサーを作っており、そのうちブログで紹介できると良いなと思っているが未定


April 2022


Ziglangにはまだ公式のパッケージマネージャが存在してない。(22/4/17時点)

以下のIssueで仕様に関して議論されているステータス。

<https://github.com/ziglang/zig/issues/943>

そのため、exeやlibで他のパッケージを利用する場合には、`git submodule`かサードパーティのパッケージマネージャを使う必要がある。

submoduleはよいとして、サードパーティのパッケージマネージャは現状自分が調べた範囲内だと以下の2つが存在している。

- Gyro
  - <https://github.com/mattnite/gyro>
  - <https://astrolabe.pm/>
  - 322 Stars(22/4/17時点)
- Zigmod
  - <https://github.com/nektro/zigmod>
  - <https://aquila.red/>
  - <https://nektro.github.io/zigmod/>
  - 253 Stars(22/4/17時点)

ただ、現状はサードパーティのパッケージマネージャを使うよりはsubmoduleを使うほうが無難な気がする。

依存パッケージが増えて管理ができないみたいな困りごとが発生したら使うくらいだろうか。


Zigのパッケージマネージャに関して調べた

Ziglangのパッケージマネージャ


元々S3 + Cloudfrontで構築していたこのサイトだが、今日思い立ってCloudflare Pagesに移行した。

<https://pages.cloudflare.com/>


## 元々の構成について

以前の構成は以下の記事に書いた。

[このサイトの構築に関して](/entries/2021-11-14/about-backend-of-this-site/)

自分で構築したほうがカスタマイズできるというのと、Cloudfront周りの素振りをしたかったのでこの構成にした記憶がある。

## 移行した理由

- 気分が乗った
  - これが一番でかい
- Cloudflare Workersを今後使ってみたかった
  - このサイトに使うかはわからないが、Pagesなど周辺サービスの理解にはなりそうかなと
- デプロイが若干面倒だった
  - 記事を書き終わったあと、`aws s3 sync --delete`で毎回手動デプロイしていた
  - 自動化しろって話ではあるんだが、GitHub Actionsの枠を気にしたくなかったり、CodeBuildはあまり使いたくなかったしで気が乗らなかった
- 前の構成に満足した

## デプロイに関して

[コンテンツ](https://github.com/ytakhs.com)と[サイト実装](https://github.com/ytakhs/ytakhs.com-frontend)とでリポジトリが別れているので、新しくリポジトリを作りsubmoduleで束ねる形にした。

`git submodule update --remote`してプッシュすればCloudflare Pagesの方で自動的にデプロイが始まる。

リポジトリが別れてるせいでこれでも若干面倒だが許容範囲ではある。

## 所感

これからCloudflare Workersとか色々触ってみたい。

今このサイトはNext.jsで作っているが、[Remix](https://remix.run)とかで作り直すのも良さそうと思っている。


サイトのインフラをCloudflare Pagesに移行した

Cloudflare Pagesに移行した


このサイトを Atom1.0 のフィードに対応させた。

Atom の仕様把握も兼ねて、RSS 対応する便利 package とかは使わずに、自分で XML を組み立てた。

## 仕様

仕様は以下を軽く読んだ。

- <https://datatracker.ietf.org/doc/html/rfc4287>
- <https://validator.w3.org/feed/docs/atom.html>
  - こっちのほうがわかりやすかった

また ValidatorW3C の方には Validator も整備されており、書いた XML が仕様的に問題ないかを確認できる。

- <https://validator.w3.org/feed/check.cgi>

## 実装

実装は node-xml を使った。

<https://github.com/dylang/node-xml>

パッケージ名は`xml`で、これと Typescript 用`@types/xml`しか依存が増えず、軽量でよい。(更新は止まってるようだが)

以下みたいに実装すればよい。

```typescript
import xml from "xml";

const feed = {
  feed: [
    { _attr: { xmlns: "http://www.w3.org/2005/Atom" } },
    { id: baseURL },
    { title: [{ _attr: { type: "text" } }, "foo"] },
    { link: [{ _attr: { rel: "alternate", href: baseURL } }] },
    {
      link: [
        {
          _attr: {
            rel: "self",
            href: new URL("/atom.xml", baseURL).href,
          },
        },
      ],
    },
    { author: [{ name: "bar" }] },
    { updated: updatedAt },
    ...entries.map((entry) => {
      return {
        entry: [
          { id: entry.permalink },
          { title: { _cdata: entry.title } },
          { updated: entry.createdAt },
          { summary: { _cdata: entry.summary } },
          { link: [{ _attr: { rel: "alternate", href: entry.permalink } }] },
          { published: entry.publishedAt },
        ],
      };
    }),
  ],
};

xml(feed, { declaration: { encoding: "UTF-8" } });
```

`xml`メソッドに `declaration` オプションをつけると`<?xml version="1.0" encoding="UTF-8" ?>`みたいな宣言を先頭に付与してくれる。

`declaration` はなくてもよいが、推奨されているのでつけておくのが良さそう。

<https://www.w3.org/TR/xml/#sec-prolog-dtd>

> Definition: XML documents should begin with an XML declaration which specifies the version of XML being used.


サイトを自前実装でAtom1.0に対応させた記録

Atom1.0のフィードに対応した


<https://blog.rust-lang.org/inside-rust/2022/04/04/lang-roadmap-2024.html>
<https://lang-team.rust-lang.org/roadmaps/roadmap-2024.html>

Rust 2024 に向けてのロードマップとして 以下の 3 つの題目それぞれのビジョンや未来について書いてある。

- Flatten the (learning) curve
- Help Rust's users help each other
- Help the Rust project scale

## 所感

各題目に対して`How you can help`のセクションがあるなど、オープンな姿勢が感じられて良かったし自分も何かコントリビュートしたくなった。

直近で検討中の新機能として紹介されている`let-else`や`let-chains`はあったら便利そうだなと思った。

[`let-else`](https://github.com/rust-lang/rfcs/pull/3137)は以下のような構文。

```rust
let a = foo.bar() else {
  return Err("error");
};
```

[`let-chains`](https://github.com/rust-lang/rust/issues/53667)は以下のような構文。

```rust
if let Some(bar) = foo.bar()
  && let Some(baz) = foo.baz()
  {
    return Ok(());
  }
```

他にも色々検討中のものが紹介されていた。

- <https://rust-lang.github.io/impl-trait-initiative/explainer/tait.html>
- <https://rust-lang.github.io/generic-associated-types-initiative/>
- <https://rust-lang.github.io/async-fundamentals-initiative/explainer/async_fn_in_traits.html>
- <https://github.com/rust-lang/lang-team/issues/88>
- <https://github.com/rust-lang/lang-team/issues/137>

Rust 開発チームが鋭意進行中のプロジェクトは以下のサイトを見るのが良さそう。

<https://lang-team.rust-lang.org/initiatives.html>

Rust は好きな言語だけど、なかなか学習にもコストがかかったり書くのが大変だったりは感じてたので、今後どう進化していくのか楽しみ。


Rust 2024に向けてのロードマップを読んだ


<https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/>

- Deployment とは異なり、管理する Pod の順序や唯一性を担保してくれる。
- volumeClaimTemplates によって定義される PersistentVolume を各 Pod が持つ。
  - すべての Pod に対して 1 つの PersistentVolume をもたせる場合は Deployment を使う。
- 各 Pod がそれぞれ Volume を持つことが保証されているので、DB のレプリケーションなどに向いてそう
- Headless Service が必要で、ClusterIP などは利用できない(2022/4 時点)
  - DNS は`<Pod名>-{0..N}.<Service名>.<Namepace名>.svc.cluster.local`のようになる
  - 例えば`<Pod名>-0`をプライマリ DB,それ以外をレプリカ DB、みたいな構成にできる
- MySQL を構築している例
  - <https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/>

## 参考

- <https://eng-blog.iij.ad.jp/archives/9998>


k8sのStatefulSet


<https://kubernetes.io/docs/concepts/workloads/controllers/deployment/>

例えば ↑ のドキュメントから拝借した Deployment に、`metadata.labels`, `spec.selector.matchLables`,`spec.template.metadata.labels`の 3 つがある。

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80
```

それぞれ、以下のような役割になっているようだ。

- `metadata.labels`
  - Deployment 自体に付与される label
- `spec.selector.matchLabel`
  - Deployment に所属させる対象の Pod の label
- `spec.template.metadata.labels`
  - Pod に付与される label

特に`matchLabel`は`template.metadata.label`から拝借してくれないのか、という疑問はある。

が、Deployment 自体が ReplicaSet、ひいては Pod のラッパー？みたいなものだと考えると、まあそんなもんかとも思う。

## 参考

- <https://medium.com/@zwhitchcox/matchlabels-labels-and-selectors-explained-in-detail-for-beginners-d421bdd05362>


k8sのlabelsが色々ある件


HTTP ヘッダで、リソース間の関係を表現するための仕様で、`Link`というフィールドを定義している。

<https://datatracker.ietf.org/doc/html/rfc8288>

Web アプリケーションを作る上では REST API のオフセット形式のページネーションで使われている印象。

例えば GitHub の REST API にもページネーションの仕様として Link ヘッダが利用されている。

<https://docs.github.com/en/github-ae@latest/rest/overview/resources-in-the-rest-api#link-header>

このサイトは特にページネーションを実装してないが、仮に Web Linkng で実装するとしたら以下のようになりそう。

```
Link: <https://ytakhs.com/entries?page=3>; rel="next",
      <https://ytakhs.com/entries?page=2>; rel="prev",
      <https://ytakhs.com/entries?page=1>; rel="first",
      <https://ytakhs.com/entries?page=99>; rel="last"
```

GitLab も同様に API のオフセット形式のページネーションで WebLinking を利用していて、こちらはオープンソースなので実装も見れる。

<https://gitlab.com/gitlab-org/gitlab/-/blob/4784d4e4607a8876feffc85935ba8dc0c29496a2/lib/gitlab/pagination/offset_header_builder.rb#L36>

なお、実際にこれでページネーションを作るとなると、結局ページ数やレコード数の合計も返す必要があるが、その仕様はないので独自ヘッダを作る必要がありそう。

## 余談: 独自ヘッダの命名

ページ数やレコード数の合計を独自ヘッダで返すとなった場合、どんなフィールド名にするかという議論になると思われる。

GitLab は`X-Total-Pages`,`X-Total`のようなヘッダで表現しているが、独自ヘッダに`X-`というプレフィックスはやめようという話もあるようだ。

- <https://zenn.dev/ys/articles/a58b02e3cbc2f839f7f1>
- <https://datatracker.ietf.org/doc/html/rfc6648>

だからどうすべきという話ではないが、頭の片隅には入れておいてよさそう。


Web Linking


## 技術

- Next.js でブログを作りなおした
  - <https://github.com/ytakhs/ytakhs.com-frontend>
- WebAssembly に興味でてきたので、wat(WebAssembly Text Format)を書いてみたりしていた
  - <https://developer.mozilla.org/ja/docs/WebAssembly/Understanding_the_text_format>
  - <https://booth.pm/ja/items/3060039>
- [Tauri](https://tauri.studio/)でメモアプリを作ろうと思ったが、作りたいものが迷走してしまったため断念した
  - 結局 Scrapbox で十分なのではという結論になった
  - プロダクト作るって難しい

## 書いた記事

5 本書いた。ブログを作り直したことで月の中頃は書く気力が湧いていくつか書いたが、下旬には失速してしまった。

- [WebAPI の CSRF 対策を調べた](/entries/2022-03-08/csrf/)
- [Next.js の Rendering パターン](/entries/2022-03-09/nextjs-rendering/)
- [Next.js でサイトを作り直した](/entries/2022-03-14/nextjs-blog/)
- [February 2022](/entries/2022-03-15/monthly-report/)
- [IMWheel で Ubuntu 環境のマウスのスクロールのスピードを調整した](/entries/2022-03-19/imwheel/)

## 所感

- 4 月は WebAssembly でなにかしらアウトプットしようと思う
- Zig もやっていきたい


March 2022


Ubuntu 環境でマウスのホイールを使ったスクロールが遅いので、imwheel を使って調整した。

やったことは基本すべて以下に載っている。

<https://wiki.archlinux.jp/index.php/Imwheel>

自分が行ったのは以下の設定。

- .imwheelrc を設定
- systemd のサービスとして IMWheel を起動

## 設定上の注意

Arch のドキュメントにも書いてあるが、戻る・進むボタンなどがマウスのボタンに割り当てられている場合 imwheel 起動時に`-b`オプションをつけないと、戻る・進むが効かなくなる可能性があるので注意(自分の環境だと効かなくなった)

`-b`は`--buttons`オプションで、imwheel がどのボタンを認識するかを制限できる。

引数には Button Number を指定する(以下`man imwheel`より引用)

```
Index   Interpreted As    Button Number   Name in imwheelrc
1       Wheel Up          4               Up
2       Wheel Down        5               Down
3       Wheel Left        6               Left
4       Wheel Right       7               Right
5       Thumb Button 1    8               Thumb1
6       Thumb Button 2    9               Thumb2
7       Extra Button 1    10              ExtBt7
8       Extra Button 2    11              ExtBt8
etc.
```

デフォルトだと`-b "4 5 6 7 8 9"`が設定されている。

尚、Arch のドキュメントでは`-b 45`と指定しているが、Ubuntu の`man`には以下のように書いてある。

> The button-spec must be sur‐rounded by quotes. Each button number must be separated by a space.

もしかしたら引数の指定方法は環境とかバージョンによって異なるのかもしれないので`man`を確認したほうが良さそう。

自分は上下左右のスピードを調整したかったので systemd に以下のように設定した。

```
ExecStart=/usr/bin/imwheel -b "4 5 6 7"
```

これでマウスのホイール操作がサクサク動くようになった。


IMWHeelでUbuntu環境のマウスのスクロールのスピードを調整した

IMWheelでUbuntu環境のマウスのスクロールのスピードを調整した


今更ながら 2 月の月報的なものを書いてみる。

どれくらい続けられるかわからないが、前月やったことの備忘録兼振り返りとして残していければよいなと思っている。

## 技術

- Zig 言語で JSON のパーサを書こうとして途中まで書いて設計上の問題が発覚しやめてしまった

  - <https://github.com/ytakhs/json-parser-zig>
  - メモリ管理の部分の理解が曖昧なまま作ってしまって行き詰まってしまったので、もう少し Zig の理解を深めて再チャレンジしたい
  - Rust は以前書いた
    - <https://github.com/ytakhs/json-parser-rs>

- next.js のチュートリアルをやった
  - <https://nextjs.org/learn/foundations/about-nextjs>

## 所感

- Zig の書き味は個人的に Rust よりも好みなので、今後は Zig をもっと書いて行きたいと考えている
  - 業務で使えないであろうマイナー言語を学んでいていいのだろうかという気持ちもあるにはあるが...
  - Rust を採用する企業も増えてきたので、Rust を学んでたほうが仕事には繋がりそうではある


February 2022


以前[Zola](https://www.getzola.org)で作ったこのサイトを Next.js で作り直した。

[https://ytakhs.com/entries/2021-11-10/first/](/entries/2021-11-10/first)

ちょうど諸事状で Next.js のプロジェクトに関わる機会があり、その素振りとして試しに使ってみている。

また今回はソースコードも public にした。

<https://github.com/ytakhs/ytakhs.com-frontend>

↑ はソースコードのみで実際のコンテンツはそのうちまた Next.js から別の実装にリプレイスすることを想定し別のリポジトリに分割した。一緒にしておくとリプレイス時に倒そうなので。

コンテンツは今の所 private のままだがそのうち public にする予定。

## 主に使用した技術

- 言語

  - TypeScript

- フレームワーク

  - [Next.js](https://nextjs.org)

- スタイル

  - [tailwindcss](https://tailwindcss.com)

- Markdown パーサー
  - [react-markdown](https://github.com/remarkjs/react-markdown)
  - 内部で[remark](https://github.com/remarkjs/remark)が使われている。

上記にプラスして linter などいろいろ試しに入れてみた。

また、インフラは S3 + Cloudfront から変更してない。

コンテンツのディレクトリ構成としては以下のように`/entries/yyyy-MM-dd/slug/`の中に index.md や画像を入れる構成にしている。

```
.
└── entries
    └── 2022-03-14
        └── nextjs-blog
            └── index.md
```

一点困った点として、Next.js は画像などの静的ファイルは public 配下に配置するしかなく、画像ファイルを index.md と同階層に置けないという問題が発生した。

[next-optimized-images](https://github.com/cyrilwanner/next-optimized-images)というライブラリを使えば解決できるというような記事も見かけたが、このライブラリ自体数年メンテナンスが止まっており、中身も Webpack の設定追加を行うようなものだったため今後の Webpack 仕様変更などで壊れる可能性(そもそも現状でも動くかわからないが)もあり、採用を見送らざるを経なかった。

結局どうしたかというと、`public/entries`を Git 管理から外し、ビルド時にコンテンツから`public/entries`に画像をコピーする、という戦略を採用した。

画像を多用する予定は今の所ないため、これで一旦は大丈夫なはず。

あと一般的な静的ファイルのサイトを作るには`trailingSlash: true`の設定も必要だった。

これにより export 時に`xxx.html`ではなく`/xxx/index.html`を生成してくれるようになる。

<https://nextjs.org/docs/api-reference/next.config.js/trailing-slash>


Next.jsでサイトを作り直した


以下に SSG と SSR とが紹介されているものの、Next.js は静的ファイル生成もサーバー起動もでき、何がどの機能に属しているのか混乱したので自分用にまとめた。

<https://nextjs.org/docs/basic-features/pages#two-forms-of-pre-rendering>

## Pre-rendering

### 静的ファイル生成

`next export`で HTML,CSS, JS などを生成し CDN などから配信する方法。

以下にあるようにいくつか利用できない機能がある。

<https://nextjs.org/docs/advanced-features/static-html-export#unsupported-features>

### サーバー起動

`next start`でサーバーを立ち上げる方法。

#### SSG

`next start`を実行する前に、`next build`を実行する必要があるが、そこで生成されたものをそのままレスポンスとして返す。

`getServerSideProps`関数を定義しなければ自動的にこれになると思われる。

なお、動的なルーティングのページ(`/pages/:id`など)は通常 SSG できないが、Next.js では`getStaticPaths`関数の fallback オプションを true もしくは blocking にすることで静的に生成できなかったページをレンダリングすることができる。

<https://nextjs.org/docs/api-reference/data-fetching/get-static-paths#fallback-false>

<https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration>

#### SSR

これは Next.js のサーバーへのリクエスト時に HTML を生成する。

`getServerSideProps`関数内で、外部サーバーからデータを取得できたりする。

## CSR

Pre-rendering で生成した HTML に対して JS で動きがつけられる。よくあるブラウザ上での JS の DOM 操作。


Next.jsのRenderingパターン


ブラウザから WebAPI 作る際に、CSRF 対策どうすればよいのかイマイチ自信がなかったので調査した。

## CSRF とは

以下がわかりやすそう。

<https://www.ipa.go.jp/security/vuln/websecurity-HTML-1_6.html>

## 対策方法

いろいろなサイト調べてそこそこの分量の文章を書いたけど結局 OWASP Cheet Sheet にいろいろなパターンあったのでこれを読むのが良さそうと思い全部消しました。

<https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html>

OWASP とは、Open Web Application Security Project の略で、Web アプリケーションのセキュリティ向上を目的としたコミュニティ。

<https://owasp.org>

Cheet Sheet には CSRF 以外の脆弱性についても書いてあるので困ったら参照すると良さそう。

## まとめ

- 原則フレームワークが提供している防御機能を使う
- それが難しい場合は OWASP にいろいろな対策が掲載されているのでそれらを検討する
  - その他セキュリティに詳しい人や団体の情報を参考にする
- 間違ってもその辺のブログに書いてあるような対策方法をそのまま真似しない

という心づもりでいるのが良さそう。


WebAPIのCSRF対策を調べたときのメモ

WebAPIのCSRF対策を調べた


TradingView で移動平均線を引くメモ。

TradingView では Pine 言語なるスクリプト言語を書くことでインジケータを引くことができる。

移動平均線にもいろいろあり、TradingView のコミュニティでも様々なものが公開されており利用することができる。

自分は 50 日と 200 日の単純移動平均線を一度に引けるものが欲しかったため、自作することにした。

```
//@version=5
indicator(title="$MA", shorttitle="MA", overlay=true)

src = input.source(close, title="closing price")

ma_50_length = input.int(50, title="50-day", minval=1)
ma_200_length = input.int(200, title="200-day", minval=1)

ma_50 = ta.sma(src, ma_50_length)
ma_200 = ta.sma(src, ma_200_length)

plot(ma_50, color=color.orange, title="50-day moving average")
plot(ma_200, color=color.blue, title="200-day moving average")

```

参考

- <https://tradetech.online/tradingview-indicator-ma3/>
- <https://www.tradingview.com/pine-script-docs/en/v5/Introduction.html>
- <https://jp.tradingview.com/pine-script-reference/v5/>


TradingViewで移動平均線を引くメモ

TradingViewで移動平均線を引く


先日、MacBook Pro 2015 を Apple の下取りに出した。

これは自分がプログラマとして生計を立てていこうと決めたときに、当時まだ学生の身であったが無理して買ったもの。

この PC であれこれ勉強し、そのおかげで今があるといっても過言ではない。

ただ、2 年前くらいに ThinkPad 買ってからはずっと ThinkPad を使っているため、もうしばらく使わなくなっていた。

元々 Apple の下取りは購入時にのみ行えるものかと思って敬遠していたが、たまたま調べてみたところギフトカードで受け取れるということを知り、行動するに至った。

さらば私の Macbook Pro。今まで本当にありがとう。

---

下取りは以下から導線にしたがって行った。

<https://www.apple.com/jp/trade-in/>

シリアル番号を入れてデバイスを検索し、いくつかの質問(傷はないかなど)に答え、住所などの個人情報を入れて申し込んだ。

申し込んだのち、自分の場合は 2 日後くらいに発送キットが届いた。

発送する前に以下の手順にしたがって Mac を初期化をしておくことが推奨されている。

<https://support.apple.com/ja-jp/HT201065>

自分の場合は写真などが残っており、そこそこな容量だったので必要なファイルはすべて S3 に適当にアップロードしてしまった。

初期化した後、佐川急便の集荷を依頼し、受け渡して作業は完了。

---

まだ査定は来てないが、画面などにいくらか傷がついてしまっているので過度の期待は禁物かなと思っている。

今後特に Apple 製品を買うときは特にケースに入れるなど取り扱いは気を付けていきたい。

作業としては初期化などは面倒だがそれ以外は負担なくでき、体験としてはそこそこよかった。

追記:

デバイスを発送してから 2 ～ 3 日後くらいに下取り額確定のメールが届いた。

結果としては見積りと同額となった。多少使用感があっても致命的な傷がついているとかでなければ基本は見積と同じで買い取ってくれるようだ。


MacBook Pro 2015をAppleの下取りに出した話

MacBook Pro 2015をAppleの下取りに出した


このサイトは S3 + CloudFront で構築している。(2021/11/14 時点)

GitHub Pages とか Netlify とか他にも選択肢はあったが、自分で構築してカスタマイズしたいという気持ちがあったので自前で構築した。

この S3 + CloudFront 構成に関して主に 2 つの選択肢が存在する。

1. S3 の Website Hosting 機能を使い、前段に CloudFront を配置する
2. CloudFront の OriginAccessIdentity 経由で配信する

---

<https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html>

1 の Website Hosting は構築は 2 と比較して楽。

ただし、S3 バケットのコンテンツを public な状態にする必要があったり、CF との通信が http になったりする点がイマイチ。

別に重要な情報を扱うわけではないのでそれでも問題はないのだが、あまり妥協したくもなかったので 1 は選択肢から外した。

---

<https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html>

2 はコンテンツを public にする必要はなく、CloudFront の Origin Access Identity に対するポリシーだけ付与すればよいためセキュアにはなる。

ただし、S3 の Website Hosting と違い、CloudFront のコンテンツ配信だけだとルートディレクトリ以外の index.html を補完してくれない。

例)

- Expected
  - /foo/bar => /foo/bar/index.html を読み取ってほしい
- Actual
  - /foo/bar => /foo/bar を読みとろうとし、403 エラーになる

これを解決するために、CloudFront Functions でリクエストされたパスを変換するような構成にした。

CloudFront Functions は 2021/5 月に利用できるようになった機能。

<https://aws.amazon.com/jp/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale/>

Lambda@Edge よりも制約はあるものの 1/6 のコストで実行することができるため、パス変換くらいの軽い処理であればこれで十分。

あとロールとかポリシーとかの管理も不要なので楽。

実装は以下の記事を参考にした。

<https://aws.amazon.com/jp/blogs/compute/implementing-default-directory-indexes-in-amazon-s3-backed-amazon-cloudfront-origins-using-lambdaedge/>

S3 + CloudFront 構成のパス変換 Lambda@Edge で対応する記事だが、CloudFront Functions でも同様にできた。

実際に CloudFront Functions に設定したコードは以下。

```js
function handler(event) {
  var request = event.request;

  var oldUri = request.uri;
  var newUri = oldUri.replace(/\/$/, "/index.html");

  request.uri = newUri;

  return request;
}
```

注意点としては、CloudFront Functions では ECMAScript 5.1 準拠な JS しか使えないため、新しい JS の機能は利用できない。

そのため変数宣言も`const`ではなく`var`を使っている。

---

そのうち飽きたら別の構成になってる可能性はあるが、しばらくはこの構成でいきたい。


このサイトの構築に関して


何回目か分からないがまたブログを作り直した。

毎回最初に CSS とかいろいろこねくり回した挙句に、ちっとも記事を書かずに終わるので、今回は見てくれは気にせずに取り合えず記事を書いていくことにする。

あと、自分が書いたものをどう見られるのかを気にしすぎてしまうのもあって、完璧に書こうとしてしまうのもよくない。

文章の練習と思って、気楽に書こうと思う。

そのうち英語の記事とかも書きたい。

---

書く内容は技術的なものにこだわるつもりもない。

日常のことも書くかもしれないし、投資とかのことも書くかもしれない。

内容は未定ではあるが、なるべく書き続けたいとは思っている。

自分の脳内整理のための文章を、外にも公開しているくらいの気楽さでいきたい。

おそらく読む人も変に気取ったものよりもそういった文章の方が面白いのではないだろうか。(少なくとも自分はそういうゆるい文章は好きだ)

---

ブログの構築には Zola という Rust 製のジェネレータを使ってみている。

<https://www.getzola.org/>

使ってみた感想としては、シンプルに作られていて結構よさそう。

コマンドも serve, build など最低限必要なものくらいしかない。

後々自作のものに置き換えたくなるかもしれないので、Hugo みたいないろいろできてしまうものよりは、これくらいシンプルの方がよい。
