
## はじめに

ベクトルデータベースざっと調べた感じいくつか候補がありました。

- [Weaviate](https://weaviate.io/)
- [Elasticsearch](https://medium.com/gsi-technology/vector-databases-made-easy-51483c4e44d7)
- [Deep Lake](https://www.deeplake.ai/)
- [Pinecone](https://www.pinecone.io/)
- [Milvus](https://milvus.io/)
- [Qdrant](https://qdrant.tech/)

## 基準として何を気にしていたか

- ローカル環境を立ち上げられること
- データ構造がいい感じか
- upsert ができるか
- API がいい感じか

## どれも同じかと思ったら Weaviate が一味違かった

1. Docker イメージが用意されている
2. GraphQL API が用意されている
3. 内部で Embedding の module が用意してあってベクトル化もしてくれる
4. RDB の構造をそのままベクトルとして扱える

全部やばいが、特に 4 がやばい。他のベクトルデータベースは、文字列のベクトル + メタデータという感じだが、
Weaviate は、Class という概念とそれに付随する Properties という概念があって、例えば Author という Class の Properties を全部ベクトル化してくれる。
しかも、Author に紐づく Article とかもアソシエーションを定義できる。
なんでこの圧倒的違いが話題になっていないのか分らないけど個人的にはグッときた。

例えば、こんな感じのデータがって、

```json
{
  "name": "Alice Munro",
  "age": 91,
  "born": "1931-07-10T00:00:00.0Z",
  "wonNobelPrize": true,
  "description": "Alice Ann Munro is a Canadian short story writer who won the Nobel Prize in Literature in 2013. Munro's work has been described as revolutionizing the architecture of short stories, especially in its tendency to move forward and backward in time."
}
```

これをそのままベクトルデータに渡すことができる。

```json
{
    "id": "779c8970-0594-301c-bff5-d12907414002",
    "class": "Author",
    "properties": {
        "name": "Alice Munro",
        (...)
    },
    "vector": [
        -0.16147631,
        -0.065765485,
        -0.06546908
    ]
}
```

しかもアソシエーションも定義できる。

```json
{
    "id": "779c8970-0594-301c-bff5-d12907414002",
    "class": "Author",
    "properties": {
        "name": "Paul Krugman",
        ...
        "writesFor": [
            {
                "beacon": "weaviate://localhost/32d5a368-ace8-3bb7-ade7-9f7ff03eddb6",
                "href": "/v1/objects/32d5a368-ace8-3bb7-ade7-9f7ff03eddb6"
            }
        ]
    },
    "vector": [...]
}
```

これで何が実現できるかというと、
「A さんが投稿している記事に多く登場する単語は？」みたいなデータを跨いだセマンティック検索が可能。
これまでは、構造化データどうすんねんと思ってたけどこれで解決できそう。


Weaviate というベクトルデータベースは一味違かった


## ベクトルデータベースとは？

複雑なデータは急速なペースで増えている。これらは、文書、画像、動画、ウェブ上のプレーンテキストなど、構造化されていないデータの形態を含んでいる。

多くの組織は、複雑なデータの保存と分析を必要としているが、複雑なデータは、構造化されたデータを念頭に置いて構築された従来のデータベースでは扱いが難しい場合がある。キーワードやメタデータのみで複雑なデータを分類することは、そのさまざまな特性を十分に表現するには不十分かもしれないと考えている。

幸いなことに、機械学習（ML）技術は、ベクトル埋め込みに変換することで、複雑なデータのはるかに有益な表現を提供できる。ベクトル埋め込みは、数百または数千の異なる次元で数値として複雑なデータオブジェクトを記述する。ベクトルデータベースは、ベクトル埋め込みのユニークな構造を処理するために特別に作られていて、ベクターをインデックス化し、値を比較して互いに最も類似したものを見つけることで、簡単に検索や取得ができる。

## 機械学習の台頭により、ベクトル検索は構造化されたデータ検索よりも強力に

OpenAI API のリリースや、Langchain のようなツール、Pinecone のようなベクトル DB サービスの登場により、ベクトル検索の利用がこれまで以上に手軽になった。

過去数ヶ月で、多くの人が非構造化データを使い始め、実験を重ねている。

では、構造化データについてはどうだろう？

Langchain のような LLM ツールチェーンによって紹介されている方法は、言語モデルが SQL クエリを生成する方法だ。

これは一見素晴らしいように見えるが、実際に試してみると、単にゲームのコントローラーを有線から無線に変更するようなもので、画面上の実際のゲーム映像はまったく変わらない。かなり自然な検索結果を返すと思われるベクトル検索とは対照的に、リレーショナルデータベース検索は時代に取り残されてしまったようだ。

ただし、厳密な検索のための構造化であって、単純に自然言語に十分に対応していないというのは誤りではないと言う人がいるのは予想できる。

それは本当にそうだろうか。

## メインの非構造化データ（文書）とそれに関連する構造的な関連性（例えば時間/人物）

この問題で最も影響があるのは、組織内ドキュメントや業務メッセージだ。これは、文書やメッセージ自体が強い非構造化の側面を持っている一方で、いつ更新されたのか、誰が書いたのかという情報を常に含んでいるため、非構造化と構造化の両方の視点が必要。

もちろん、Web のように文書自体に日付や著者情報が含まれる可能性が高い場合はあまり問題ではないが、問題は、RDB で完全に管理されている組織内の文書やチャットで起きる。

## 解決策の案

このドキュメントやチャットの問題に対処するため、以下の暫定的な対策を踏むことにした。ベクトル化されるテキストに関連情報を埋め込む。

従来のテキスト:

```
これは意味のありそうな文章だ。
```

解決するためのテキスト案:

```
タイトル: 意味のありそうな文書
著者: 山田太郎
更新日: 2023-04-16
本文: これは意味のありそうな文章だ。
```

私の実験では、「誰がどの情報に精通しているか」、「重複した内容についてどの情報が正しいか」といった質問に対して、適切な回答が得られた。

---

これは提案です。皆さんの意見をお聞かせいただきたい。


非構造化データ検索の台頭と、LLM時代における構造化データ検索への対応


## はじめに

https://vercel.com/docs/storage/vercel-postgres

Vercel Postgres の発表を受けて、個人的に

- Typescript で Postgres を利用する**シーンが増えそう**
- Vercel が wrapper を用意している **Kysely** という**クエリビルダー**の存在が気になり始める
- **Prisma** は使っていたが、複雑なクエリになると辛いシーンもあった
- `vercel/@postgres` は `pg` の wrapper だった。そもそもクエリビルダーや ORM を使うという**前提を疑ってみたい**

というあたりが頭の中でつながりはじめ、今回の記事で、Typescript で SQL を利用する方法を改めて検討してみました。

## 登場するもの

### DB ドライバ

手動で TCP パケットを生成してデータベースに配信します。データベースへの接続やコネクションプールを処理することになります。このレベルでは、生の SQL 文字列を書いてデータベースに渡し、データベースから応答を受け取ることになります。

例）

- [pg - npm](https://www.npmjs.com/package/pg)
- [mysql - npm](https://www.npmjs.com/package/mysql)
- [sqlite3 - npm](https://www.npmjs.com/package/sqlite3)

### クエリビルダー

SQL のクエリを Typescript で記述することができます。

例）

- [knex - npm](https://www.npmjs.com/package/knex)
- [kysely - npm](https://www.npmjs.com/package/kysely)

### ORM

名前の通り、RDB のレコードを、アプリケーションのオブジェクトにマッピングします。

例）

- [sequelize-typescript - npm](https://www.npmjs.com/package/sequelize-typescript)
- [prisma - npm](https://www.npmjs.com/package/prisma)
- [bookshelf - npm](https://www.npmjs.com/package/bookshelf)

## 全体の流れ

1. とりあえず ORM vs クエリビルダー、クエリビルダー vs ドライバの順にそれぞれの意見を見ていきます。
2. 感想
3. 実践

## 🙋‍♂️ ORM を使う人たちの意見

### みんな使っている

なぜか世の中の情報が多い。ActiveRecord の功績？

### データベースを簡単に差し替えられる

例えば、Postgres と MySQL の両方に対応している ORM を利用していれば、"比較的"簡単に行き来することができる。（頻度はともかく）

### ORM はオブジェクト指向のクエリ手法を SQL に変換できる

- アプリケーションはオブジェクト指向で書かれているのでその文脈で SQL を記述できる
- インターフェイスの記述に重点を置かないことでビジネスロジックに集中できる
- データベーススキーマとオブジェクト（型）を DRY に管理できない

### SQL を厳密にマスターするのは大変

- しっかりとしたトランザクションサポートがある
- SQL インジェクションの脆弱性をガードする

### 生のクエリもサポートしている

これにより、開発者は生のクエリを書くための手段も併用できる。

### TypeScript の力を借りたい

- 補完
- 型チェック

## 🙋‍♂️ クエリビルダを使う人たちの意見

### SQL を生で書くのは動的なクエリで辛い

`pg`:

```ts
client.query(
  'INSERT INTO users(name, email) VALUES($1, $2) RETURNING *',
  [name, email],
  (err, res) => {
    /** .. */
  }
)
```

Kysely:

```ts
kysely.selectFrom('users').where('name', '=', name).where('email', '=', email)
```

### ORM では実現できないクエリがたまにある

巨人の ActiveRecord でさえも実現できないクエリがあり、結局生の SQL を書く、というケースがある。

### 複雑な ORM での記述は非効率になる場合がある（パフォーマンス）

Kysely:

```sql
SELECT
  post.*, user.name AS user_name, user.email AS user_email
FROM
  post
LEFT JOIN
  user ON user.id = post.user_id
WHERE
post.category_id = ?;
```

Sequelize:

```sql
SELECT
  "category"."id", "category"."name", "user"."id" AS "user.id",
  "user"."name" AS "user.name", "user"."email" AS "user.email",
  "user->post"."category_id" AS "user.post.category_id",
  "user->post"."user_id" AS "user.post.user_id",
  "user->post"."unit" AS "user.post.unit"
FROM
  "user" AS "user"
LEFT OUTER JOIN (
  "post" AS "user->post"
  INNER JOIN "user" AS "user" on "user"."id"  = "user->post"."user_id"
) ON "category"."id"  = "user->post"."category_id"
WHERE
"category"."id"  = ?
```

### 生のクエリもサポートしている

これにより、開発者は生のクエリを書くための手段も併用できる。

### TypeScript の力を借りたい

- 補完
- 型チェック

## 🙋‍♂️ データベースドライバを直接利用する人たちの意見

### 特定の ORM やクエリビルダーを学んだとしても、言語やライブラリを跨いで知識を活かせない

例えば、同じ Node.js のライブラリでも Sequelize と Prisma では微妙に記述が違う。

Sequelize:

```ts
const users = await user.findAll({ where: { name: 'Kevin' } })
const user = users[0]
const id = user.dataValues.id
```

Prisma:

```ts
const users = await db.user.findAll({ where: { name: 'Kevin' } })
const user = users[0]
const id = user.id
```

対して、SQL の方言はほんの数種類しかない。
生の SQL を使ってクエリを生成する方法を学ぶことで、この知識を異なる言語を簡単に行き来することができる。

## 感想

### 実感できたところ

- ORM をいちいち覚えたくない
- SQL に精通しておきたい
- Typescript で補完してほしい
- ORM だと痒い所に手が届かない

### 不安に感じたところ

- 生で SQL を書いた場合のトランザクションや SQL インジェクション対策
- スキーマと type (オブジェクト)で記述が重複するのはどうなんだろ...

### 困らないかもと思ったところ

- クエリビルダーの仕様ってシンプルなので覚えるのは簡単そう

### 一旦の結論

- クエリビルダーを使ってみたい
- Prisma で schema を定義するのはやっぱやりたい

## 💪 Typescript での実践（Kysely x Prisma）

とりあえず、Prisma でスキーマを定義しつつ、kysely でクエリを書いていきます！

こんなものもあるみたいですが、今回は自分で書いていきます。
[valtyr/prisma-kysely: 🪄 Generate Kysely types directly from your Prisma schema!](https://github.com/valtyr/prisma-kysely)

`schema.prisma`:

```prisma
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id        Int       @id @default(dbgenerated("uuid()"))
  createdAt DateTime  @default(now())
  updatedAt DateTime  @updatedAt
  email     String    @unique
  name      String?
  posts     Post[]
}

model Post {
  id          Int      @id @default(dbgenerated("gen_random_uuid()"))
  createdAt   DateTime @default(now())
  updatedAt   DateTime @updatedAt
  title       String
  body        String?
  user        User     @relation(fields: [userId], references: [id], onDelete: Cascade)
  userId      Int
}
```

ここで注意するところは、`@default`です。
Prisma では一般的に、以下のように定義しますが、**これは JS ベースの実装なので、Kysely を利用して insert した場合には、実際のデータベースに反映されません。**

```schema
@default(gen_random_uuid())
```

ということで、以下のように SQL ベースの UUID を利用します。

```diff
- @default(uuid())
+ @default(dbgenerated("uuid()"))
```

Kysely の初期化。
ここでは、`@prisma/client` から `User`、`Post` を Kysely に渡しています。

```ts
import { Pool } from 'pg'
import { Kysely, PostgresDialect } from 'kysely'
import { User, Post } from '@prisma/client'

interface Database {
  User: User
  Post: Post
}

const db = new Kysely<Database>({
  dialect: new PostgresDialect({
    pool: new Pool({
      connectionString: process.env.DATABASE_URL
    })
  })
})

export { db as kysely }
```

実際に操作してみる:

```ts
const posts = kysely.selectFrom('Post').where('userId', '=', 1).execute()
```

## まとめ

一旦は、schema とオブジェクトを Prisma に任せ、Kysely でクエリを組むということをやってみました。これでしばらく試してみたいと思います。補足やアドバイス等ありましたらお願いします！


Typescript でのDBドライバ、クエリビルダー、ORMについて真面目に考える（pg、Kysely、Prisma）


## Vercel の Visual Editing

なんかブラウザで CMS のコンテンツを編集できるやつです。

https://twitter.com/vercel/status/1653791607609761799?s=20

[Visual Editing | Vercel Docs](https://vercel.com/docs/workflow-collaboration/visual-editing)

> Visual Editing, currently in a limited private beta, is accessible for Enterprise Teams using Sanity as their content editing workflow. To participate in this or future private betas, contact us for more information.

> Visual Editing は現在、限定的なプライベートベータ版で、Sanity をコンテンツ編集ワークフローとして使用しているエンタープライズチームがアクセスできます。このプライベートベータや今後のプライベートベータへの参加をご希望の方は、弊社までお問い合わせください。

とのことなので、CMS [Sanity](https://www.sanity.io/) を試しに使ってみようと思います。

## Sanity Web でプロジェクトを用意

この辺はぽちぽちやってけば大丈夫です。

最後に、 local で立ち上げる sanity の管理画面 （studio と呼ばれているらしい） をインストールするコマンドを教えてくれました。

```
npm create sanity@latest -- --template get-started --project *** --dataset production --provider google
```

というわけで、Sanity にはクラウドの管理画面がないみたいです。
この studio をどこかに deploy すれば、コラボレーションもできるようです。

https://www.sanity.io/solution/collaboration

#### 追記: 2023/05/06

公式のドキュメントに deployment の紹介があるようです！

https://www.sanity.io/docs/deployment

## Next.js の環境にインストール

```diff
  ./
  ├── pages/
  │   ├── ...
+ │　　　　　　└── studio/
+ ├── sanity/
+ │   ├── lib/
+ │   ├── schema.ts
+ │   └── schemas/
+ ├── sanity.cli.ts
+ ├── sanity.config.ts
  ├── package-lock.json
  ├── package.json
  ├── ...
```

- `./sanity/` - なんかデータの schema やらなんやら
- `./pages/studio/` - `localhost:3000/studio` で管理画面が開ける

## 実際にデータを編集する

画面はこんな感じ。別に使いやすくはなかったです。

![](https://storage.googleapis.com/zenn-user-upload/4e2ac678da93-20230505.png)

## Next.js から呼び出す

大まかには以下のような感じ。

```ts
import { createClient } from 'next-sanity'
import { apiVersion, dataset, projectId } from '@/sanity/env'

const client = createClient({
  projectId: projectId,
  dataset: dataset,
  apiVersion: apiVersion,
  useCdn: false
})

export const getStaticProps = async () => {
  const posts = await client.fetch(`*[_type == "post"]`)
  // ...
}
```

気になるところは後述します。

## 辛かったところ

### クエリが独自

とにかくクエリを覚えないといけないのが微妙でした。Copilot がなかったら補完も効かない。

[How GROQ Queries Work - Step by Step Guide](https://www.sanity.io/docs/how-queries-work)

```ts
client.fetch(`*[_type == "post" && slug.current == ${slug}]`)
```

#### 追記: 2023/05/06

一応 GraphQL サポートがあるようです。

https://www.sanity.io/docs/graphql

### ~~ブログの Body とかが、HTML 文字列じゃなくて、ブロック構造になっているが、Parser は自前で用意しろスタイル~~ Portable Text という規格を採用してるみたい

こんな感じで、結構気を遣って構造化してくれているんですが、Parser が用意されてないので、HTML に直すところでめんどくさくなり諦めました。

```ts
body: [
  {
    style: 'h2',
    _key: 'f8a7d4e3e019',
    markDefs: [],
    children: [Array],
    _type: 'block'
  },
  {
    markDefs: [],
    children: [Array],
    _type: 'block',
    style: 'normal',
    _key: '78957f0d9762'
  }
  // ...
]
```

#### 追記: 2023/05/06

Portable Text という規格に則っているようです。

https://github.com/portabletext/portabletext

公式でライブラリが紹介されていたので試しに使ってみようと思います！

https://www.sanity.io/docs/presenting-block-text

### せっかく Schema as Code なのに、Type や Interface がない

ので、自前で用意しました。

#### 追記: 2023/05/06

有志がライブラリを作ってくれているみたいです！

https://github.com/ricokahler/sanity-codegen

## まとめ

ドキュメントを一通り読みましたが、抜け漏れがあるかもしれません。補足等お願いします。

#### 補足: 2023/05/06

色々補足していただいて、懸念点が払拭されつつありますので改めて使ってみようと思います！
特に Portable Text あたりは勉強になりました。


Sanity CMS


これの話っすね。
[Introducing storage on Vercel – Vercel](https://vercel.com/blog/vercel-storage)

Heroku で動いてたアプリと比べてみた。

## 差分

```diff
diff --git a/Procfile b/Procfile
deleted file mode 100644
index bc6eb1f..0000000
--- a/Procfile
+++ /dev/null
@@ -1,2 +0,0 @@
-release: npx blitz prisma migrate deploy
-web: npm run start:production
diff --git a/db/schema.prisma b/db/schema.prisma
index 0f8f549..3a35c9b 100644
--- a/db/schema.prisma
+++ b/db/schema.prisma
@@ -2,8 +2,9 @@
 // learn more about it in the docs: https://pris.ly/d/prisma-schema

 datasource db {
-  provider = "postgresql"
-  url      = env("DATABASE_URL")
+  provider          = "postgresql"
+  url               = env("POSTGRES_PRISMA_URL") // uses connection pooling
+  shadowDatabaseUrl = env("POSTGRES_URL_NON_POOLING") // used for migrations
 }

 generator client {
diff --git a/package.json b/package.json
index f6484ea..a1e0358 100644
--- a/package.json
+++ b/package.json
@@ -3,14 +3,13 @@
   "version": "1.0.0",
   "scripts": {
     "dev": "blitz dev",
-    "build": "blitz build",
+    "build": "blitz prisma migrate deploy && blitz build",
     "start": "blitz start",
     "studio": "blitz prisma studio",
     "lint": "eslint --ignore-path .gitignore --ext .js,.ts,.tsx .",
     "test": "vitest run --passWithNoTests",
     "test:watch": "vitest",
-    "prepare": "husky install",
-    "start:production": "blitz start --port $PORT"
+    "prepare": "husky install"
   },
   "prisma": {
     "schema": "db/schema.prisma"
```

## 結果

|             | Vercel               | Heroku        |
| ----------- | -------------------- | ------------- |
| Migration   | `npm run build`      | `Procfile`    |
| Deploy time | 1m30s                | 4m            |
| Performance | Good                 | Good          |
| Pricing     | Free (〜 1 Database) | $7.00 + $9.00 |

## 結論

よき。Vercel がんばれ。


Vercelがやりよった (Vercel Postgres)


https://guide.uxai.dev で [GitBook](https://www.gitbook.com/) を使ってみました。

構成としては、

https://github.com/moekidev/ai-conversational-ux-guide/tree/main/guides

```
guides
├── en
└── ja
```

です。

GitBook には、team, collection と space と言う階層があって、

- team
  - collection
    - spaceA
    - spcaeB
    - ...

みたいな感じになります。

今回は、

- UXAI.DEV
  - AI Conversational UX Guide => `guide.uxai.dev`
    - en => `/v/en`
    - ja => `v/ja`

みたいな構成にしました。

team, collection, space どれにも custom domain が設定できてその辺りがややこしかったです。

以上。

GitBookが楽しかった


https://github.com/uxaidev/AI-Conversational-UX-Guide

https://guide.uxai.dev/v/en

以下、冒頭の抜粋です。

**大規模言語モデル**を利用したアプリケーションの普及により、アプリケーション開発者は、未知なる**会話型 UX**について考えることになりました。 このガイドでは、言語モデルのアプリケーション上での振る舞いの特性と会話型 UX を設計する際の指針についてまとめています。

言語モデルをアプリケーションに組み込んだ際に、アプリケーションのインターフェースは、**自然言語**となります。 これが、ユーザーはアプリケーションと会話するように見えることから会話型 UX という言葉を利用しています。

このような UX を最初に普及させたのは OpenAI です。彼らは、ChatGPT という大言語モデルをリリースしました。 これは、特に会話型 AI としての性能を重視してチューニングされていおり、質問応答、文書生成、要約作成など、多様なタスクをこなすことができます。

ChatGPT の登場以降、さまざまなアプリケーションが会話型 UX を採用してきましたが、**従来のルールを採用したが故にユーザー体験が損なわれている**ケースをたびたび目にしてきました。 そこでこのガイドラインでは、新しい UX のルールについて検討していきたいと思います。

---

Contributing お待ちしております 🙏


AI Conversational UX Guide


今回の例では、Langchain を利用してますが、多分本家の API だけでも対応できると思います。

[Welcome to LangChain | 🦜️🔗 Langchain](https://js.langchain.com/docs/)

まずはサーバーサイド。

```typescript
import { ChatOpenAI } from "langchain/chat_models"
import { HumanChatMessage } from "langchain/schema"
import { CallbackManager } from "langchain/callbacks"

const api = (req, res, ctx) => {
  if (req.method !== "POST") return
  const input = req.body.input

  const chat = new ChatOpenAI({
    openAIApiKey: OPENAI_API_KEY,
    streaming: true
    callbackManager: CallbackManager.fromHandlers({
      async handleLLMNewToken(token: string) {
        res.write(token)
      },
    }),
  })

  await chat.call([new HumanChatMessage(input)])

  res.end()
})
```

ポイントは、`streaming: true`でストリーミングを有効にして、[`write()`](https://nodejs.org/api/stream.html#writable-streams) でストリーミングを有効にします。これは Node.js の Writable streams というもので、ファイルやレスポンスに対して有効になります。

全部 Langchain の処理が終わったら `end()` で終了してあげます。

次はクライアントサイドです。

```typescript
const reply = async (input) => {
  const decoder = new TextDecoder()

  const res = await fetch(ENDPOINT, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      input
    })
  })
  const reader = res?.body?.getReader()

  let output = ''

  while (true) {
    if (reader) {
      const { value, done } = await reader.read()
      if (done) break
      output += decoder.decode(value)
    }
  }
}
```

ポイントは [`getReader()`](https://developer.mozilla.org/ja/docs/Web/API/ReadableStream/getReader)ですね。あと、decode しないといけないのでその処理を入れておきます。

これで OK。


ChatGPT 本家のようなストリーミング出力を実現する


## 会社の場合

僕は会社で使っている非公開のメモはありません。
メモは全部 Kibela に書いて、みんなが見られる状態になってます。

別に見られて困るものもないし、
完成度の低いものを載せて怒られることもないので。
そもそも Kibela はそういう設計です。

## プライベートの場合

僕の場合は必要ないです。

メモることって、誰かにとって有用だったりするので。

そんなに極秘プロジェクトもやってません。

なんなら、コードスニペットやブックマークも公開してもいいと思います。


非公開のメモって必要なんですかね？


新しいドキュメントツールのベータ版をリリースしました。

[https://www.ink-o.com](https://www.ink-o.com/)

https://www.youtube.com/watch?v=ew_q-Ieuiws&t=65s

私はこれまで、Notion や Evernote をうまく使いこなせませんでした。その原因の多くは、フォルダやファイルの管理の難しさです。例えば、毎日のノートを日付ごとに分けるべきか、トピックごとに分けるべきか...

一方で、Slack のようなチャットツールに自分の考えを吐き出すというフローは、とても得意だと感じています。そのおかげで仕事がスムーズに進むことも多いです。分報と呼ばれる、管理するための報告フローがありますが、やっていることは実質これと同じです。ただし、私の場合、完全に頭の中を整理するためだけにやっています。

ただ、ほとんどの場合、チャットにはマークダウンのような高度な表現方法がありません。例えば、コードスニペットや引用を残す機能がないですよね。

そこで、チャットとドキュメントのハイブリッドを思いつきました。
このアイデアは ChatGPT での経験から生まれたもので、チャットと自由な表現の組み合わせはとてもいい感じでした。

![画像説明](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vowimth6opspi6gp18qk.png)

今回のリリースでは、まだ AI への対応はしていませんが、もしかしたらそれによって、このツールの真価を発揮するかもしれません。そこで、このツールに対する皆さんのアイデアを募集したいと思います。以下の Github Discussions で、皆さんのアイデアをお待ちしています。

[https://github.com/moekidev/ink-o/discussions](https://github.com/moekidev/ink-o/discussions)


ズボラな私のためのメモツールを開発した


会社で興味深い表現を聞きました。

外部サイトは別タブで開くのをデフォルトにした方がいいんじゃないかという提案をしたら、
別タブで開くかどうかはユーザーが決められた方がいい。とのこと。

確かに。

別タブで開くはオプション


このツイートをしてみて考えたことを書きます。

[Moeki Kawakami さんは Twitter を使っています: 「音声 AI の Bark、シチュエーションをちゃんと設定してプロンプトを組むと、相当リアルになる。ドキッとする。 https://t.co/gkVRdQPgvP」 / Twitter](https://twitter.com/moekidev/status/1649932748331839488)

## 前提

私は Text to Speech をまともに触ったのは初めてです。GitHub を見た感じ、Google Colab で手軽に動かせそうだったので試そうと思いました。

## 音声生成 AI の日本語のサンプルが少なすぎる

こちらの @yuto_v2_nissy さんがおっしゃっていることが誇張表現であるとは全く思っていません。おそらく専門の方ならこのくらいのクオリティに当たり前のように触れているんだと思います。

[Yuto Nishimura さんは Twitter を使っています: 「このモデルが動いてることに感動するなら分かるけど、 クオリティに驚いてる人たちは tts 初見なんか？」 / Twitter](https://twitter.com/yuto_v2_nissy/status/1649960330209148929?s=20)

しかし、今回改めてネット上で調べてみたのですが、一般人が触れられる日本語の音声生成 AI のサンプルが少なすぎる気がします。 というかこの Bark 以外のものがほとんど見つけられませんでした。

また、Bark に対する専門家からの意見が少なすぎるのも感じました。いくつかツイートは見かけたのですが、一般人にも簡単に理解できる評価の裏付けをしている方は少なかったように思います。

もう少しモデルを正しく評価できる環境が整っているとより良いと思いました。

## 結局サンプルの精度はどうだったのか？

### Bark はまだ日本語の学習が十分でない

ようです。

- 何も考えずにプロンプトを渡すと雑音、謎の間、不自然なアクセントが多分に含まれました。

また、素人目には学習データの傾向にこんなものがあると感じました。

- データ量が少ない
- シチュエーションに偏りがる
- 音質が良くない
- 音声以外の雑音が混じっている

### 学習データに近しいシチュエーションのプロンプトを渡すと上手くいく

ということで、今回は、学習データと似ていると思われるシチュエーションを意図的に選びました。

### どうやってシチュエーションを特定したか？

「こんにちは。これはテストです。」など基本的なプロンプトで、音質とイントネーションを聞き取り、学習データの傾向を推測しました。

- マイクの音質に聞こえたので講演系の音源でないかと思った
- 標準語の要素が明らかに少ないと思った
- また、BGM が流れているものがあったので、おそらく作品から抽出したのではないかと考えた（つまり演技もの）
  
## 学習モデルの評価と学習量の評価の扱い

この学習モデルは、学習量が多ければ上手くいく気がする的な予測ができるのか正直素人には分かりません。ただ学問的には明確な答えがある気がしてます。詳しい方教えてください。

## まとめ

今回の場合少なくとも一般層には興味深く写ったようです。ただし以下の条件付きでした。

- 一般的な音声生成 AI の性能に関する情報が限られている
- 学習データに寄せたプロンプトを利用している

ありがとうございました。


音声生成AIってすごいんですねえ


OpenAI は ChatGPT API をリリースして以来、続々と派生サービスを展開しています。なぜリリースして以来というのを強調したかというと、悪意があるように感じてしまうくらいのタイミングだと思うからです。つまり、そのタイミングとは、API を利用してプロダクトを開発している人たちがアイデアを形にしようとしているタイミングだということです。

ここで一旦 OpenAI の動きを振り返ってみましょう。

参考:

[hollobit/GenAI_LLM_timeline: ChatGPT, GenerativeAI and LLMs Timeline](https://github.com/hollobit/GenAI_LLM_timeline)

### 2022-11-30: ChatGPT リリース

このタイミングで、OpenAI がどこまで想定していたのか分かりません。ユーザーがプロンプトという概念に慣れていく序章に過ぎないという感じだったのでしょうか。

### 2023-03-01: ChatGPT API リリース

このリリースのタイミングは絶妙だったように記憶しています。人々が LLM の概要を理解し、アイデアを溜めていた状態でした。リリース後 1 週間は API を利用したサービスがたくさんリリースされましたが、傾向としては、

- 既存プラットフォームでの利用
- 特定のユースケースのプロンプトを GUI に
- PDF などのデータを入力としてチャットボットを生成

あたりで、まだまだシンプルなものが多かったと思います。

### 2023-03-14: OpenAI の利用規約更新

[Usage policies](https://openai.com/policies/usage-policies)

ここでは、ChatGPT API を利用したやり取りは学習に利用しないということが明言されました。ここでさらに API を利用したプロダクトが一気に増えた印象がありました。

### 2023-03-23: ChatGPT plugins 発表

[ChatGPT plugins](https://openai.com/blog/chatgpt-plugins)

ChatGPT の GUI から外部サービスとの連携を実現できる plugins が発表されました。次世代のモバイルアプリになるのではないかという予想を立てていましたが、まだ利用には制限があり、どうなるか分かりません。

ただし、外部サービス x プロンプト UI のプロダクトについては、この plugins で完結できることは間違いなく、開発者の工数が減り、それと同時に ChatGPT 本体にエンゲージメントを取られる形となると思われます。

また、プロンプト型の UI で実現できるものは plugins に吸収されることは明らかだと思います。

### Microsoft や Google が LLM を利用したサービスを発表

この辺りでは、業務特化型の既存サービスは Microsoft Office や Google Workspace で完結できる傾向があることが判明しました。

### 2023-04-26: OpenAI Brand guidelines

[Brand guidelines](https://openai.com/brand)

ここでは、〇〇 GPT というプロダクト名を推奨しないことが明言され、今後は ChatGPT を利用したサービスの存在感がこれまでよりも弱くなる傾向が予想されます。

### 2023-04-27: ChatGPT Business 発表

[New ways to manage your data in ChatGPT](https://openai.com/blog/new-ways-to-manage-your-data-in-chatgpt)

ここでは、ChatGPT の Web UI でも企業のデータを学習に使わないプランを考えていることが発表されました。つまり、ChatGPT API のポリシーがそのまま適用されます。これで、企業向けに ChatGPT の導入を進めていたプロダクトにとって不利な状況になったと思われます。

## OpenAI の考えの考察

OpenAI は ChatGPT の Web UI をプラットフォームとして展開することがユーザーにとってより良い体験につながるという考えを持っていると感じています。これは、プロダクトを開発している立場としてはとても納得できます。ユーザーにとってサイトを行き来したり、サービスを使い分けることがいいことだとは考えにくいです。

我々（開発者）は何をするべきか？

これまでの流れと今後の展開の予想から以下のことに注力するべきだと思っています。

1. これまでと同様に、ChatGPT を主体としないプロダクトを発想する（AI 時代に必要なものとは何なのか？）
2. 既存プロダクトと LLM との連携について考える
3. ChatGPT plugins を開発する
4. ChatGPT 単体もしくは、既存プラットフォーム（Microsoft / Google）では解決できない「UI」を考える

4 で強調した「UI」とは、つまり、プロンプト UI でできてしまうことは、plugins に吸収されてしまうからです。

以上です。補足などがあればよろしくお願いします。


OpenAI が ChatGPT プラットフォームを展開する中、我々がやるべきは何なのか


> この記事は、以下の動画のトランスクリプトを GPT-4 にブログ記事としてまとめてもらったものです。（YouTube のトランスクリプトでは、固有名詞がカタカナになっていましたが、GPT-4 に直してもらいました！）

https://www.youtube.com/watch?v=mZNtroAh_ws

こんにちは！今回は、Amazon の Code Whisperer と GitHub の Copilot を使って、ブログポストを作成するプロジェクトに取り組んでみました。この記事では、それぞれのツールの特徴と、どのようにそれらを使ってブログポストを書くことができるかについて解説します。

## 概要

Code Whisperer と Copilot は、どちらも AI を使ってコード補完を行うツールですが、それぞれ異なる特徴があります。この記事では、React と Next.js を使ったブログポストの実装を行い、両ツールの使い勝手や補完精度を比較してみました。

## Copilot の特徴

- GitHub のコードから言語を問わずに予測してくれる
- Blitz のようなマイナーなフレームワークにも対応している
- React の基本的な部分がほとんど出てくる
- テキストエリアやアラートの出力が良い

## Code Whisperer の特徴

- 言語ごとに学習データを分けて学習している
- マイナーな言語には対応していない
- Tailwind CSS の保管が強力
- React の補完も一部できるが、学習が足りていない部分もある

## 結果

実際にプロジェクトを進める中で、Copilot は React の基本的な部分や Blitz のようなマイナーなフレームワークにも対応している点で優れていました。一方で、Code Whisperer は Tailwind CSS の保管が強力であることが特徴でした。ただし、マイナーな言語や設定ファイルには対応していないため、対応状況を確認しながら使うことが望ましいです。

## まとめ

Copilot と Code Whisperer は、それぞれ異なる特徴を持つコード補完ツールです。どちらのツールも一長一短があり、プロジェクトや好みに応じて選ぶことが重要です。これらのツールを使って開発を進めることで、効率的にコードを書くことができます。特に、React や Next.js、Tailwind CSS などのよく使われる技術に対しては、どちらのツールも優れた補完を提供してくれます。

ただし、どちらのツールも万能ではなく、マイナーな言語やフレームワークに対する対応状況は異なります。そのため、プロジェクトを始める前にツールの対応状況を確認し、自分にとって最適なツールを選択することが重要です。

また、どちらのツールもまだ学習が足りていない部分があるため、完全に AI に頼るのではなく、自分自身の知識と経験を活かしてコードを書くことが大切です。これらのツールは、あくまで補助として活用し、自分のスキルを磨いていくことが重要です。

最後に、Copilot や Code Whisperer などの AI 技術は日々進化しています。今後も新しい機能や対応言語が追加されることで、より便利で効率的なコーディングが実現できることでしょう。開発者として、これらのツールの進化に目を光らせ、自分にとって最適な開発環境を構築していくことが大切です。


【コード補完AI】Amazon Code Whisperer を Github Copilot と比べてみた

GPTのベースとなってる技術についてChatGPTと一緒に勉強してみた


最近、私はブログ実装ツールとして、Next.js の Astro を検討しました。

私が最も重視したかったのは、ユーザーエクスペリエンスでした。ページを閲覧するためにはどちらの方法がより快適でしょうか？

そのため、彼らの製品でページが実装されているため、彼らのドキュメントを検証しました。

- [Getting Started | Next.js](https://nextjs.org/docs/getting-started)
- [Getting Started 🚀 Astro Documentation](https://docs.astro.build/en/getting-started/)

答えは非常に明確でした。Next.js のドキュメントに同意し、単一ページサイトが非常に快適だと思いました。Astro のドキュメントでは、最初のページの読み込みは速いですが、リンクをクリックすると遅くなります。Next.js のドキュメントは常に軽量です。

最終的に、私は将来的にブログを Next.js で実装することを決定しました。フレームワークのドキュメントを経験したことに基づいて決定しました。単一ページサイトは標準になるのでしょうか？それとも、マルチページサイトは必要かつ十分なデザインとして生き残るのでしょうか？


シングルページサイトが標準になるのか？


AWS が Finch を発表した。

[コンテナ開発用のオープンソースクライアント「Finch」のご紹介 | Amazon Web Services ブログ](https://aws.amazon.com/jp/blogs/news/introducing-finch-an-open-source-client-for-container-development/)

筆者は Mac を使っていて、Docker Desktop または、[colima](https://github.com/abiosoft/colima)　 x 　 Docker CLI を利用して、Docker の開発環境を実現している。Dcoker Desktop は内部で[HyperKit](https://github.com/moby/hyperkit)（macOS hypervisor）を利用して Linux の VM を立ち上げ、その中で dockerd を実行している。Docker 導入当初は Docker Desktop を利用していたが、Docker Desktop の GUI は使っていなかったので、よりシンプルな colima に移行した。colima は Lima をベースに

- Lima の設定ファイルを生成して Linux 環境を準備
- Linux on Lima の環境に Docker をインストール
- ホスト側(つまり macOS 側)の Docker CLI と Docker on Linux on Lima を透過的に接続できる環境を用意

ということを行なって、Docker 開発のサポートをしてくれる。この時点で、Lima の存在は認知していたが、AWS の記事を見ると Lima 自体結構盛り上がっているようだ。

今回の Finch の発表、つまり Alternative Docker の参入の背景はどんなものがあるのだろうか？正直言うと Kubernetes は実際に利用したことがなく疎いため、Kunernetes が Docker をやめた話を今回の Finch をきっかけに以下の記事を見つけ始めて認識した。

参考：[Docker から containerd への移行 (NTT Tech Conference 2022 発表レポート) | by Akihiro Suda | nttlabs | Medium](https://medium.com/nttlabs/docker-to-containerd-4f3a56e6f2b6)

詳細を見てみると、従来、Kubernetes は分散環境上のコンテナ管理のために Docker を触っていたが、近年は[containerd](https://containerd.io/)を直接利用するようになったらしい。

![](https://miro.medium.com/max/1400/1*HL7tRfSRwv8fLleLRDvDXQ.webp)
https://speakerdeck.com/ktock/dockerkaracontainerdhefalseyi-xing?slide=7

containerd を直接利用？containerd？コンテナ技術何も分かっていなかったことが分かった。
containerd は元々、Docker の下でコンテナの基本的な管理機能を提供するデーモンとして、2015 年に Docker 社により開発された。containerd のスコープは徐々に拡大して、現在では、Docker Engine のほぼ全てをカバーしているようだ。例えば、[nerdctl](https://github.com/containerd/nerdctl)は containerd の CLI だ。UX は Docker CLI とほぼ同じで、Docker Compose も対応している（`nerdctl compose`）。

Kubernetes に話を戻すと CHANGELOG によれば、dockershim という Docker の CRI（Container Runtime Interface）　のメンテナンス上の問題が起きていた模様。

> Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available.

[kubernetes/CHANGELOG-1.20.md at master · kubernetes/kubernetes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation)

整理すると、containerd が Docker から生まれ派生し、独自に領域を増やすと同時に、Kubernetes のメンテナンス上の問題によって Docker ではなく containerd が選ばれ、containerd を直接管理するための方法も理由も揃ってきたということになるか。そして、これらを背景にして、Finch の登場となった。Finch は containerd, nerdctl と Lima を組み合わせたツールだ。Finch 登場以前は、containerd を利用する場合は、Lima を直接利用する場合がほとんどだっただろう。

さらに Finch の記事には[BuildKit](https://github.com/moby/buildkit)についても触れられているのでこちらも抑えておこう。これまでと同様に Docker との関係性を中心に理解していこうと思う。私も身に覚えがあって、`DOCKER_BUILDKIT=1 docker build .`のようなものを目にする機会があった。これは Docker で BuildKit を利用する方法だ。BuildKit には Docker デフォルトのビルドに対して以下のようなメリットがあるようだ。

- 複数ステージのビルドを並列実行できる
- 機密情報をビルド成果物(キャッシュを含む)に残さない仕組み(Dockerfile 内の RUN --mount コマンド)が使える
- ローカルファイルをビルド時のみに使える
- リモートファイルをビルド時に SSH 接続して取得できる
- ビルドキャッシュのインポート/エクスポートが出来る
- 分散ビルドが出来る

なるほど。ビルドキャッシュや並列実行は強力そうだ。Finch ではこれらの機能をデフォルトで利用できるという認識で良いかと思う。

Finch の意義を理解できたところで、実際に使ってみよう。

```
brew install finch
```

まず、finch の構成を設定することをしてみた。README に沿って以下のように設定してみた。

```yaml:~/.finch/finch.yaml
cpus: 8
memory: 8GiB
```

そして vm を初期化する。

```
finch vm init
```

これで vm が立ち上がった。
次は Docker CLI や nerdctl と同じように、Docker Compose を利用してみる。

```
finch compose up
```

ここで、Docker と containerd との挙動の違いにいくつか出会ったので紹介しておく。

まず、port の省略的な記述が無効だった。

```diff:compose.yaml
  db:
    ports:
-     - 5432
+     - 5432:5432
```

あとは、context の外のファイルを読み込もうとするとエラーになった。今回はファイルの置き場所を変えることで対応した。

```diff:compose.yaml
  app:
     volumes:
-      - ~/.gitconfig:/root/.gitconfig
+      - ./.gitconfig:/root/.gitconfig
```

それ以外は、Docker の場合と同じだった。

以上、Finch をきっかけに containerd やコンテナ周辺の技術についての理解を深めることができた。今後は徐々に Finch への移行を進めていった方が潮流に乗ることができるような気がしている。


Finchでcontainerdに入門した


この記事は、以下の Podcast を要約したものです。

[29. The Aesthetic of Technology Selection (2) w/ twada | fukabori.fm](https://fukabori.fm/episode/29)

この Podcast では、コンピューティングが発展してきて、分散コンピューティングと集中コンピューティングのトレンドが来たり行ったりしていること、そして、この広い歴史的なトレンドを要約している。

著者は、2019 年以降業界に関わっているという前提で話をしている。

この記事では、用語をより詳しく見ていく。

## Good Old Web

最初に、ビジネスシステムなどが[Visual Basic](https://ja.wikipedia.org/wiki/Visual_Basic)と SQL サーバーを使用していることについて話している。これは、2000 年頃の話で、画面と SQL だけの 2 層アーキテクチャーであると説明されている。これは、[Next.js](https://nextjs.org/)の開発体験に似ているように感じた。

次に、@t*wada 氏がモノリシックな[LAMP(Linux, Apache, MySQL, PHP)](<https://en.wikipedia.org/wiki/LAMP*(software_bundle)>)の不動産検索サービスを開発したことが聞かれた。PHP でレンダリングされた HTML を表示するだけのブラウザが行っていた単純な作業の時代であり、Java Servlet なども主流であった。これは 2002 年頃である。

ここで、Visual Basic と SQL の 2 層アーキテクチャから LAMP の 3 層アーキテクチャへの移行があった。これは、集中コンピューティングから分散コンピューティングへの流れの始まりである。そして、分散コンピューティングへのトレンドは次のセクションでさらに強化された。

## EJB や SOAP を使った分散コンピューティング

ビジネスシステムは複雑で再利用可能な部品が多く、複数のシステムを接続する需要がありました。

このような問題を解決する文脈で、ビジネスロジックを実装するコンポーネントである[EJB（Enterprise Java Beans）](https://ja.wikipedia.org/wiki/Enterprise_JavaBeans)が登場しました。

[SOAP（Simple Object Access Protocol）](<https://ja.wikipedia.org/wiki/SOAP_(%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB)>)は、[XML](https://ja.wikipedia.org/wiki/Extensible_Markup_Language)ベースの[RPC](https://ja.wikipedia.org/wiki/%E9%81%A0%E9%9A%94%E6%89%8B%E7%B6%9A%E3%81%8D%E5%91%BC%E5%87%BA%E3%81%97)プロトコルの実装です。異なる言語やオペレーティングシステムで実行されるプロセスが、XML を介して通信することができます。仕様は次第に単純でなくなり、SOAP は Simple Oriented Access Protocol の略称ではないという興味深い声明があったとのことです。

これらのアイデアは、[SOA（Service-Oriented SOA（Service-Oriented Architecture）](https://ja.wikipedia.org/wiki/%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E6%8C%87%E5%90%91%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3)に基づいています。SOA とは、単一のビジネスプロセスに対応するソフトウェア機能をサービスとして考慮し、これらのサービスをネットワーク上でリンクし、全体のシステムを構築することです。これはクラウドコンピューティングの台頭で再確認されました。具体的には、ソフトウェアを単一のビジネスプロセスに相当するユニットで構成し、オープンで標準化された技術仕様を使用してサービスインタフェースを定義する場合、SOA と見なされます。

[What is Service Oriented Architecture? Service Oriented Architecture Explained - AWS](https://aws.amazon.com/jp/what-is/service-oriented-architecture/)

## Ruby on Rails のモノリシックへの移行がもたらした影響

また、EJB や SOAP に基づく SOA の問題点は、様々なシステムを接続するために大量の設定を書かなければならないことであったが、Ruby on Rails はその反対を提唱していた点が注目されています。

実際、Ruby on Rails 以前から [Spring Framework](https://ja.wikipedia.org/wiki/Spring_Framework) や [Seasar](https://ja.wikipedia.org/wiki/Seasar) などのフレームワークがありましたが、これらのフレームワークも Ruby on Rails の登場後は影響を受け、慣例に基づいた設計がなされるようになりました。

## ウェブを基盤とする分散システム

Ruby on Rails のようなモノリシックなフレームワークは、分散システムは実装が困難であるという考え方から生まれました。しかし、身の回りに成功している分散システムがあることに気づきました。それが実際には World Wide Web でした。

分散システムの設計は、RPC から Web ベースに移行し始めました。JSON を使用したサーバー-クライアントおよびサーバー-サーバーの相互作用のアーキテクチャが増加しました。さらに、クラウドコンピューティング、コンテナ技術、継続的デリバリーの登場により、マイクロサービスなどの分散システムへの動きが再び現れています。

さらに、[GraphQL](https://graphql.org/) や [gRPC](https://grpc.io/) に象徴される、サーバー駆動型 API 定義からクライアント駆動型 API 定義へのシフトは、マイクロサービスの実現を強化しました。この点から見ると、GraphQL はサーバー側とクライアント側の合意不足を強調しています。

## 感想

知らないことが多く、継続的に進化する技術に対する印象を明確にしたと思います。今後、他の視点からも学んでいきたいと思います。


Spiral of decentralized and centralized


最近は、色々なチームの技術選定についての話を読んで勉強しています。

チーム間の技術選定の違う点さまざまありますが、その一つは、どのくらい先進的かと言うことです。

```
Progressive vs Conservative
```

技術選定の話になると必ず話題になりますよね。
よく「これを使うにはまだ早すぎる」「もうこれは古くない？」と言う議論になります。

色々な記事で技術選定の話を読んでいる中で、

- **ある技術選定に対して自分が先進的すぎるとか、保守的すぎるとか感じる基準ってなんなんだろ？**

という疑問が出てきましたので深掘りしてみたいと思います。

## どんな技術選定を先進的すぎると感じるか？

例えば、私が、ある技術採用に対して、先進的すぎると感じる場合は以下のような時です。

- 初歩的な PR や Issue が溜まっている
- 世の中で、使ってみたブログを見かけない
- ドキュメントを読んでも新しい概念が多すぎて理解できない。。

これらの感覚はすべて相対的なもので他のライブラリやフレームワークと比較しなければなりませんが、むしろそこがポイントなのではないかと理解しました。

## どんな技術選定を保守的すぎると感じるか？

逆に、以下の様な場合に保守的すぎると私は感じます。

- PR や Issue が放置されている
- 完全なる上位互換のライブラリが盛り上がっている
- 使ってみたブログの公開日がもうかなり前

## 採用する UI の選択も似た話かも

分かりやすい UI ってなんだ？ってなった時に私がよく唱える基準は、**「一般的なもの」** であるかどうかです。ユーザーは自分たちのプロダクトのみを使っているわけではないからです。いろんなアプリを生活の中で利用して日々コンピュータの使い方を学習しています。

その中で、**古き良き UI**

- 黒電話のクルクル
- フロッピーディスクの保存マーク（これは今でもあるか。。）
- スキューモーフィズム

や、**見たこともない UI**を採用すれば、ユーザーは困惑するでしょう。
これらを避けるのと同様に、技術選定でも、**他のプロダクトや業界の流れに準じる**必要があると感じました。

## 技術のリズム

**技術のリズムにノリましょう。遅れても早すぎてもいけません。**

**それは、技術が社会的なものだからです。**

技術のリズムを掴むにはどうしたらいいでしょうか。

- 実際にライブラリや言語のコミュニティに飛び込んでみる
  - リポジトリを覗いてみる
  - たくさん質問してみる
  - いいなと思ったものには積極的にコントリビュートする
- 他のチームとコミュニケーションを取る
  - カンファレンス
  - 技術ブログ
  - 失敗談を聞く

この辺りでしょうか。まあ当たり前ですが、次の点は注意する必要があるかもしれません。

## 技術のリズムとは関係ないもの

### 自分の感想

**自分で技術を触ってみた感触はもしかしたら当てにならないかもしれません。**
もし、自分にとって触り心地のいいフレームワークであっても、世間的にそうであるとは限らず、そのままお亡くなりになる可能性もあるからです。

### 技術の革新性

もしその技術を使って様々な課題を解決できる！と思っても、コミュニティが発展しきっていない場合には、セキュリティリスクやバグの対応が遅れてしまう可能性もあります。

## ただし先進的すぎたり、保守的すぎる選択が良いとされる場合もある

昔、Apple が iOS7 でフラットデザインを採用し、非難を浴びたのを思い出しました。
しかし Apple がこれまで提唱してきた多くの方針の例に漏れず、フラットデザインはいつの間にか世の中に浸透していって空気の様な UI となりました。
これは、Apple がプラットフォーマーだからだと思います。プラットフォーマーは現状の課題を打開しうるがチャレンジングな技術に**取り組むべきだし、取り組みやすい**のです。

逆に、保守的すぎる選択が良いとされる場合もあります。それは、安全性が非常に高いレベルで要求される場合などです。例えば、飛行機のコックピットなどは、新しい UI にしてしまったら混乱を招いたりするかもしれないので、かなり長いゆっくり改善をしてくはずです。

これは技術選定にも言えると思います。安全性が要求されたり、何かしらのプラットフォーマーである場合には例外的な選択をするべき場合があります。

## まとめ

- 技術選定は世間のリズムに合わせて行う
- 実は UI にも同じことが言える
- 例外的な選択をするべき場合もある

でした。


技術選定はリズムゲームだ


あなたは、こんな経験はないだろうか。iPhone を手に持ってホーム画面へ行って、「あれ？何をしようとした？」。これは端的に言えば、iPhone の利用が自己目的化している状態だ。本来何か楽しいことをするための手段であったはずの iPhone は今や目的になっている。なぜこの様なことが起きるのだろうか。実は皆さんがストアで手に入れたアプリケーションには秘密がある。あなたのアテンションを待っているという秘密だ。Twitter はあなたに広告を見てほしいし、Netflix はあなたにもっとたくさんの動画を見てほしいし、Uber Eats はあなたにもっとたくさん注文をしてほしいと願っている。利用されなければアプリを消されてしまったり、契約を終了されてしまうからだ。私はこの秘密を知った時に、インターネットの世界の収益形態はなんて不健全なんだ、と嘆いたものだが、実はこれはここ最近になって始まったものではないことに段々気がついてきた。インターネット特有の問題ではなく、テクノロジー自体の性質であることがわかった。新しいテクノロジーには、”増殖する力学が働く法則”がある。確かに、「利用されなければアプリを消されてしまったり、契約を終了されてしまうからだ」という文言は他のテクノロジーにも適応できそうだ。我々の知らないところで、自家用車と公共交通機関はお互いに顧客を巡って争い合っているようだ。自家用車の CM ではどれだけ自分の好きな道を走れることがあなたの人生にとって素晴らしいことかを謳い、公共交通機関はそれに対抗するように、環境問題や安全性を謳う。ディーラーに車検に行けば次に乗るべき自動車の話をされ、新しい車がどれだけ燃費がいいかというアピールをされる。すでに自動車に乗っている人はもう自動車からは離れられない。アテンションを要求されている。

需要者のテクノロジー利用への誘導

プロダクトやマーケティングの設計

他の需要者との社会的関係性の維持

供給者との関係性の魅力

また、一方で供給者もテクノロジーの利用をせずにはいられなくなる。世間では対して便利でもない飲食チェーンのアプリケーションで溢れかえっている。企業は、DX を推進するものたちの巧みなプレゼンテーションや、競合他社の新しいアプリケーションによって、新しい取り組みからは逃れられなくなってしまう。また、DX を推進する企業はデジタルテクノロジー自体の面白さや可能性に魅了され、それを世に広めたくてうずうずしているはずだ。まとめると以下の様な要因がありそうだ。

供給者のテクノロジー導入への誘導

企業間の競争

開発者による営業

テクノロジー自体の面白さ

なるほど。これら需要と供給側の 2 つの側面を合わせると確かにテクノロジーには、増殖法則があることが想像できそうだ。印刷や電気信号やエンジンなど、新しいテクノロジーが発明された場合に、既存の方法を片っ端から置き換えていく傾向がある。

印刷：口頭伝承 → 読書

電気信号：コンサート →LP

エンジン：馬車 → 自動車

コンピュータ：映画館 → ストリーミング

インターネット：名刺 →SNS

SNS や Google の様なインターネット以外のテクノロジーを用いたサービス/メディアにもその利用が自己目的化しているパターンは見られる。例えば、ドライブや、LP 収集、読書自慢など。これらは需要側のテクノロジー利用への誘導がインターネット以外のテクノロジーにも共通していることを表している。また、供給側についても、あるレーベルの競合他社が新しい LP というものを出せば、自分たちも同じものを出さなければ競争にならなくなると考えられる。私は、需要側にも供給側にも、テクノロジーに対するある意味での執着があり、これには二つの問題点があると考えた。

過剰なテクノロジーの置き換え

プロダクトやサービスの自己目的化による依存症

ただし、私はここで考えた。これらの問題点が現れにくいパターンがあるのでは？それはクリエイティブな活動についてだった。クリエイティブな活動の場合、テクノロジーとの健全な関係性を築けるのかもしれない。つまり、テクノロジーの増殖法則がクリエイティビティをサポートするという関係性になる。それはクリエイティブという行為自体が、新しいものへの探究（供給側の誘導）と手段に対する習熟（需要側の誘導）の両方を必要とするからだ。これは先ほどのリストをコンシューマーからクリエイターに視点を移してみてみるとよくわかる。

印刷：口頭伝承 → 執筆

電気信号：コンサート → 録音編集

エンジン：競馬 → カーレース

コンピュータ：手書きのデザイン →Adobe

インターネット：8mm フィルム →YouTube 投稿

それぞれの新しいクリエイティブについては、既存のものと比べて劣っているとか優れているという話はできないが、新しい遊び場ができたような喜びがあり、それらのテクノロジーに対する没頭がクリエイティビティを高める良い方法となることが多い。執筆の場合は、まず文字を書くということに習熟する必要がある。文字を書く技術は印刷物が普及すればするほど高めやすい。また、執筆によって、口頭伝承では伝えきれなかった、セリフのリアリティや読者ごとの最適なスピードを実現することができる。このテクニックは筆者が本を書けば書くほど洗練されていく。まとめ。

新しいテクノロジーには増殖法則がある

需要者のテクノロジー利用への誘導

供給者のテクノロジー導入への誘導

コンテンツやメディアを消費する場合には、テクノロジーの増殖に人間が翻弄される場合が多い

クリエイティブな活動をする場合には、テクノロジーの増殖がクリエイティビティを高めてくれる場合が多い


Technology Proliferation System and Creative


私は仕事上、A/B テストを行ったことがあります。やってみての感想は、A/B テストは非常に繊細で緻密なため、扱いが非常に難しいです。失敗する可能性も高いと思います。今回は、なぜ A/B テストが難しいのかについてお話したいと思います。

A/B テストとは、2 つのサイトの見た目と機能のパターンを指定された割合のユーザーに配信し、どちらのパターンが与えられたゴールを達成しやすいかをテストする方法です。目標とは、例えば、ページ遷移、ボタンクリック、コンバージョンなどです。これは、A/B テストを実施する場所によって適切に設定されることが期待される。

注意点としては、A/B テストはあくまで可能性の高いものを教えてくれるものであり、実際にリリースしたときに必ず良い結果が出るというわけではないことです。

さて、概要を説明したところで、この A/B テストがなぜ難しいのかについてお話します。まず、目標設定についてです。例えば、あるリンクからフォームに飛ぶテストをしたいとして、そのリンクが押された回数を目標値として設定するとします。この時、注意しなければならないのは、パターン B の方がリンクが押される回数が多くても、コンバージョン完了数が多くなるとは限らないということです。A/B テストでは、コンバージョン完了数など、変更を加えることで下げたくないビジネスクリティカルな指標を**ガードレ-ルメトリクス**と呼びます。

A/B テストで良い結果を出したのに、コンバージョンに影響がなかったり、マイナスになったりするパターンが実際にリリースされる理由として考えられるのは、このガードレールメトリクスが無視されていることです。

もちろん、A/B テストでは最終目標であるコンバージョン完了率を目標に設定するのがベストですが、目標の差が大きく比較できないため、コンバージョンの母数が少なくテストができないケースもあるでしょう。そこで登場するのがガードレール指標で、これは結局コンバージョン完了率を A/B テストの目標に設定したのと同じことです。つまり、流入数やコンバージョン数がかなり少ないと A/B テストはうまくいきません。

そもそもこの現象は、サイトの変更自体で起こることが多いと思います。ランディングページのようなゴールが明確なサイトでは、ユーザーがどのようにゴールを達成するのか、そのストーリーを設計する必要があります。これはマクロ的に見ても非常に重要なことです。

流入数やコンバージョン数が少ない場合は、ボタンの装飾や文言などの小さな変更ではなく、ページ数の削減やメインビジュアルのリッチ化など、ストーリーに沿った変更を行うことが効果的だと考えています。


小さなウェブサイトでのA/Bテストの難しさ


先日、自分のウェブサイトに「いいね！」ボタンを付けました。

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/61v5i2tn2mc2gmk8u1up.png)

こんなやつ。

これまでは、静的な Web サイトにちょっとしたデータベース処理を加えようとすると、アプリの実装を静的サイトジェネレータから Ruby on Rails などのサーバサイドフレームワークに変更するか、別の DB サーバを用意して API を叩くしかありませんでした。**機能によってはその追加がアーキテクチャ全体に影響を及ぼしていた**のです。

しかし、今回の実験で、Next.js と Vercel がアーキテクチャを大きく変えずにウェブサイトの機能を拡張できる、非常に**アプリケーションファースト**な思想を持っていることを実感しました。
これは、Vercel は Serverless Function で Rest API を受け取ることができることが大きく寄与しています。

見ていきましょう。

まず、「いいね！」の UI を実装します。

```jsx
import { useState } from 'react'
import { MdThumbUp } from 'react-icons/md'

export default function Component(props) {
  // props.likeCountをserver sideから取得
  const [likeCount, setLikeCount] = useState(props.likeCount)
  const [liked, setLiked] = useState(false)
  const createLike = async () => {
    if (liked === false) {
      // TODO: create like
      setLikeCount(likeCount + 1)
      setLiked(true)
    }
  }
  return (
    <>
      <span className={liked ? 'text-blue-500' : undefined}>
        <span
          onClick={createLike}
          className="ml-4 mb-4 align-bottom cursor-pointer inline-block bg-white border-2 border-gray-800 rounded-full px-4">
          <MdThumbUp className="inline mr-2" />
          {likeCount}
        </span>
      </span>
      <span className="inline-block ml-4 mb-4 align-bottom">
        {liked && <span>Thank you!</span>}
      </span>
    </>
  )
}
```

今回は ORM として、Prisma を利用したいと思います。

```
yarn add prisma
```

これがスキーマファイルである `prisma/schema.prisma` です。
今回は非常にシンプルなモデルです。

```prisma
// prisma/schema.prisma

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model Like {
  id    Int     @id @default(autoincrement())
}
```

そして、マイグレーションを生成して適用します。

```
yarn run prisma migrate dev
```

次に、データベースにアクセスするための prisma クライアントを生成します。

```
yarn run prisma generate
```

次に、実際にデータベースにアクセスする部分を実装します。

あるページから `getServerSideProps` (サーバーサイドレンダリング) という関数をエクスポートすると、Next.js は `getServerSideProps` が返すデータを用いて、リクエストごとにこのページをプリレンダリングします。ここで Like をカウントして props に渡します。

```javascript
// pages/index.js

import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()

export default function Home(props) {
  //...
}

export async function getServerSideProps(context) {
  const likeCount = await prisma.like.count()
  return {
    props: { likeCount: likeCount }
  }
}
```

続いて、Like のレコードを作成するための post エンドポイントを作成します。

```javascript
// pages/api/like/create
import { PrismaClient } from '@prisma/client'
const prisma = new PrismaClient()

export default async function handler(req, res) {
  const like = await prisma.like.create()
  res.status(201).json(like)
}
```

で、いいねボタンを押したときに発動する`ceateLike`callback に API を叩く処理を追加します。

```javascript
const createLike = async () => {
  if (liked === false) {
    fetch('/api/like/create')
    setLikeCount(likeCount + 1)
    setLiked(true)
  }
}
```

これで実装は終了です。

次に、Vercel で Prisma を使うための設定と、PostgreSQL サーバーを用意しましょう。

PostgreSQL サーバは[render](<(https://render.com/)>)で用意しました。

Vercel のドキュメントに Prisma を Vercel へのデプロイ方法をまとめてくれているので、これに沿ってやってみます。

[How to deploy a Prisma app to Vercel](https://www.prisma.io/docs/guides/deployment/deployment-guides/deploying-to-vercel)

```js
// package.json

{
  "scripts": {
    "vercel-build": "prisma generate && prisma migrate deploy && next build"
  }
}
```

次に、Prisma から Vercel への環境変数を設定します。

render の PostgreSQL から URL を取得して、
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2ceug6vaav6yerkxga0p.png)

Vercel にセットします。
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/njb5go3nvkfusb5ma8gy.png)

あとは環境変数のセットを契機に勝手にデプロイが走るので、それで終わりです。

大きなアーキテクチャの変更をすることなく、データベースの機能を追加することができました。とても自由な開発体験で、Next.js と Vercel がやろうとしていることが少し分かったような気がします。

お読みいただきありがとうございました。


Next.jsとVercel の静的サイトにPrismaでデータベースをそっと"添える"


タイトル：Prisma を使ったテスト

日付：2022 年 11 月 5 日

最近、Next.js と Prisma を使ったフルスタックアプリ開発を試しています。ちなみに、Prisma のドキュメントを見てみてください。

[Prisma を使った統合テスト](https://www.prisma.io/docs/guides/testing/integration-testing)

> 現実の環境をシミュレートする方法の一つは、Docker を使用してデータベースとテストデータをカプセル化することです。これは、テストと共にスピンアップしてダウンすることができるため、プロダクションデータベースから独立した環境として機能します。

> このガイドでは、マシンに Docker と Docker Compose がインストールされていること、そしてプロジェクトに Jest がセットアップされていることを前提としています。

そうですが、本当にテストのためにそこまで準備する必要がありますか？もっと簡単にテストを実行したいです。

そして、これは重要です。ドキュメントには、テストケースごとにデータベースを簡単にクリーンアップする方法が書かれていないため、テストが独立しておらず、テストの順序に応じて動作が変わってしまいます。

では、やってみましょう。

今回は、次のスキーマを準備しました。

```prisma
datasource db {
  provider = "postgresql"
  url      = env("DB_URL")
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String
}
```

```
npx prisma generate
```

最初に、Dotenv を使用して、テスト用のデータベースの URL を指定します。

```
npm i -D dotenv
```

```
# .env.test
DB_URL=postgresql://user:password@127.0.0.1:5432/example-test
```

次に、テストプロセスを定義します。ここでは、スクリプトの「pre」と「post」関数を使用しましょう。

```json
{
  "scripts": {
    "pretest": "pg_ctl -D db/pgdata start && dotenv -e .env.test -- prisma migrate dev",
    "test": "dotenv -e .env.test -- mocha",
    "posttest": "pg_ctl -D db/pgdata stop"
  }
}
```

ここでポイントとなるのは、Dotenv の API を使って`.env.test`を使用することです。

最後に行うべきことは、最初に申請したデータベースのクリーンアップです。mocha の場合、beforeEach、afterEach を使用してこれを行います。

```javascript
import { PrismaClient } from '@prisma/client'

export class PrismaCleaner {
  constructor(prisma = new PrismaClient()) {
    this.prisma = prisma
    const propertyNames = Object.getOwnPropertyNames(prisma)
    this.modelNames = propertyNames.filter((name) => this.isModelName(name))
  }

  async clean() {
    console.log(`Database cleaning...`)
    return Promise.all(
      this.modelNames.map((modelName) => this.prisma[modelName].deleteMany())
    )
  }

  /**
   * @param {String} name
   * @returns {Boolean}
   */
  isModelName(name) {
    return !name.match(/^(_|\$)/)
  }
}
```

```javascript
import * as assert from 'assert'
import { PrismaCleaner } from '../index.js'
import { PrismaClient } from '@prisma/client'

const prisma = new PrismaClient()
const cleaner = new PrismaCleaner()

describe('prisma-cleaner', () => {
  beforeEach(async () => {
    await cleaner.clean() # ここ
  })

  afterEach(async () => {
    await cleaner.clean() # ここ
  })

  describe('first creation', () => {
    it('creates a user', async () => {
      const user = await prisma.user.create({
        data: {
          name: 'John Lenon',
          email: 'john@example.com'
        }
      })
      assert.equal(user.name, 'John Lenon')
    })
  })

  describe('second creation', () => {
    it('creates a user', async () => {
      const user = await prisma.user.create({
        data: {
          name: 'John Wick',
          email: 'john@example.com'
        }
      })
      assert.equal(user.name, 'John Wick')
    })
  })
})
```

以上で完了です。

ちなみに、このデータベースのクリーンアップのためにいくつかのライブラリが存在することがわかりましたが、どれも完璧に機能しなかったようです。

- [emerleite/node-database-cleaner: The simplest way to clean your database after tests](https://github.com/emerleite/node-database-cleaner)
- [blazing-edge-labs/node-postgres-cleaner: Extremely simple way to clean your postgres database](https://github.com/blazing-edge-labs/node-postgres-cleaner)

とりあえず、自分でライブラリを公開することにしました。

- [cc-kawakami/prisma-cleaner: Prisma Cleaner is a utility for cleaning database with Prisma in testing. You can use in Jest or Mocha, etc.](https://github.com/cc-kawakami/prisma-cleaner)

Prisma の開発体験は予想していたほど悪くないと感じましたが、テスト環境はまだ準備ができていないと感じました。それに取り組みたかったので、この記事を書きました。

読んでくださってありがとうございました。


Prismaでのテスト


CSS なら、https://purgecss.com がある。

では Sass なら？
ビルドされた結果からだけでなく Sass のソースコードからも使っていないセレクタを抹消したい気持ちはありますよね。

試みました。[cc-kawakami/uchini: Find unused Sass codes](https://github.com/cc-kawakami/uchini)

```bash
npm i -g uchini
```

```bash
$ uchini ls --help
List CSS selectors usage

USAGE
  $ uchini ls --scss <value> --content <value> [--output
    <value>] [--unusedOnly]

FLAGS
  --content=<value>  (required) Path to content file
  --output=<value>   Path to output file
  --scss=<value>     (required) Path to CSS file
  --unusedOnly       Unused selectors only

DESCRIPTION
  List CSS selectors usage

EXAMPLES
  $ uchini ls --css path/to/css --content path/to/content --output path/to/output --unusedOnly
```

```bash
uchini ls --scss path/to/scss --content 'path/**/*.html' --output output.json
```

```json:output.json
[
  {
    "selector": ".header",
    "positions": [
      "frontend/stylesheets/_layout.scss:20:2"
    ]
  },
  {
    "selector": ".card",
    "positions": [
      "frontend/stylesheets/_card.scss:1:0"
    ]
  }
]
```

内部では以下のものを利用しています。

- [sass - npm](https://www.npmjs.com/package/sass)
- [purgecss - npm](https://www.npmjs.com/package/purgecss)
- [source-map - npm](https://www.npmjs.com/package/source-map)

まずは、Sass をコンパイルします。

```javascript
const compiled = sass.compile(scss, {
  style: 'compressed',
  sourceMap: true,
  logger: sass.Logger.silent
})
```

そして、source-map で consumer を生成します。

```javascript
const consumer = await new sourceMap.SourceMapConsumer(compiled.sourceMap)
```

次に、purgecss で利用されていない CSS セレクタを洗い出します。

```javascript
const rejectedCSS = await new PurgeCSS().purge({
  content: [content],
  css: [{ raw: css }],
  rejected: true
})[0].rejected
```

そして、consumer によってソースマップを利用して、CSS のある行に対応する Sass の行を辿ることができます。

```javascript
const position = this.consumer.originalPositionFor({
  line: 1, // compressed でソースマップが一行になっているので
  column: startOfSelector
})
```

これで終わり。


Sassでも、利用していないCSSセレクタを特定したかった


私が仕事をしている中で感じているウェブ開発チームのパフォーマンスを測る指標についてまとめて、 [WebDev Metrics](https://webdev-metrics.netlify.app/) を書いてみました。

![](https://storage.googleapis.com/zenn-user-upload/727a357c665d-20221024.png)

こちらの日本語解説になります。

## プロダクトのユーザービリティ

ユーザーが使いやすいプロダクトとはどんなものかを知っていて、ユーザーがどれだけ上手くプロダクトを使っているかを計測し、それを改善する方法を実現していなければ、プロダクトがユーザーにとって使いやすいものになりません。

例えば、タスクを完了させるまでに何ステップも操作があるとユーザーは離れていってしまし、複雑すぎると嫌になってしまいます。

また、ユーザーは自分でプロダクトをコントロールして情報を取得することはできるだけしたくないはず。空から情報が降ってくるような体験を目指してください。

ユーザー行動の結果や計測可能な指標だけでなく、プロダクトの意見を直接聞いてみると、思わぬ評価の観点を与えてくれる可能性があります。この評価も視野にいれるべきです。

また、ユーザーの満足感を直接聞いてみないと、自分たちのプロダクトが悪魔的な手法でユーザーを取り込んでいるかもしれない可能性を払拭することはできません。このような手法は、長期的に見てサービスや会社の信用を落としかねません。

参考 [The 7 most important UX KPIs and how to measure them - TestingTime](https://www.testingtime.com/en/blog/important-ux-kpis/)

## 開発パフォーマンス

どれだけリリースを軽快に行っているか？を測ることでそのチームのパフォーマンスを知ることができます。

またリリースだけでなく、バグを避けたり、バグを解消したりする能力は、プロダクトの信頼を維持するために必要不可欠です。

これらの能力のほとんどは技術的なルーチンで構成されていると思っています。それは、コミュニケーションツールや CI/CD ツール、監視ツールなどツールの仕様に依存する部分もあります。

参考 [Use Four Keys metrics like change failure rate to measure your DevOps performance | Google Cloud Blog](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance?hl=en)

## チームの効果性

開発パフォーマンスの指標を計測し、分析しても、その技術的な原因は特定できても、人間の心理的な問題までは分かりません。

チームの心理的な側面を測ることは難しいですが、いくつかの指標を心にとどめておき、チームで同意を取っておくだけで、自分たちに起きた問題に気づく可能性が高まると思っています。

例えば、心理的安全性です。これは、各メンバーが失敗を恐れず、新しいことや難しい課題に挑戦するために必要な条件です。これがなければ、新しい技術を取り入れることが難しくなったり、失敗を報告せず、チームの課題として議題に上げる機会を逃してしまいます。

参考 [re:Work - Guide: Understand team effectiveness](https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/introduction/#introduction)


ウェブ開発チームのパフォーマンスを測る指標をまとめてみた


[thoughtbot/administrate](https://github.com/thoughtbot/administrate) は管理画面用のよく知られたフレームワークですが、開発者にとっては使いづらいものでした。私は自分用の Administrate テンプレートファイルを実装しましたが、新しい Administrate のバージョンがリリースされるたびに、**テンプレートファイルが変更されるため、更新が難しくなります。**

しかし、管理画面は共通化が非常に容易なため、フレームワークやライブラリを使用したいと思っています。

そこで、これを実現しました。

[cc-kawakami/micro-admin: A minimal Administration dashboard parts.](https://github.com/cc-kawakami/micro-admin)

私は [trailblazer/cells](https://github.com/trailblazer/cells) を使用して実装したため、Ruby on Rails または他のフレームワークでも使用できます。

`ApplicationDashboard` を定義できます。

```ruby
class ApplicationDashboard < MicroAdmin::Dashboard::Base
    # もし Rails を使うなら
    self.view_paths = [Rails.root.join("app", "views", "dashboards")]
end
```

そして、それを拡張して、モデルごとにダッシュボードクラスを定義し、各画面に表示する属性を定義します。

```ruby
class UserDashboard < ApplicationDashboard
    def index_attributes
        [:id, :name]
    end

    def show_attributes
        [:id, :name]
    end

    def form_attributes
        [:name]
    end

    def model_class
        User
    end
end
```

重要な点として、MicroAdmin にはフォームアイテム用のテンプレートがないため、入力や選択などのテンプレートファイルを書く必要があります。

```html:/app/views/dashboards/user_dashboard/new/name.erb
<input type="text" name="name" class="form-control">
```

`value` 変数は、編集テンプレートに渡されます。

```html:/app/views/dashboards/user_dashboard/edit/name.erb
<input type="text" name="name" value="<%= value %>" class="form-control">
```

以下のように呼び出すことでレンダリングできます。

```ruby
smith = User.new(id: 1, name: "Smith")
james = User.new(id: 1, name: "James")
dashboard = UserDashboard.new
```

```erb
<%= dashboard.index([smith, james]) %>
```

```erb
<%= dashboard.show(smith) %>
```

```erb
<%= dashboard.new(errors: ["Name is required!"]) %>
```

```erb
<%= dashboard.edit(id: 1, values: {name: "Smith"},
```


ミニマリストのための管理画面フレームワーク


Error Reporting が最近色々進化していて、通知から記録まで隙のないサービスになっていたので全体像をまとめてみます。

## Error Reporting へエラーを送信する

GCP のインフラを利用している場合は自動で拾ってくれます。
ソレ以外の場合もいろいろライブラリがあるので調べてみてください。

## エラーのステータスを管理する

Error Reporting では、エラーのステータスを管理できます。

- **未解決**
- **確認済み**
- **解決済み**

で、確認済みにする場合は、**Github の Issue などをリンクする**ことが出来ます。

## Slack やメールでエラーを通知する

Error Reporting ではデフォルトで Slack やメールでの通知に対応しています。
通知の条件は、

- **新しいエラーが**発生した場合
- 解決済みのエラーが**再発した**場合
- **5 回以上**通知されたら、**6 時間はエラーが通知されなくなる**

なので、エラーのステータスをきちんと管理すれば、

- **対応が必要な（未知の/再発した）エラーのみ**を通知する
- 対応が必要でない（対応中の/避けられない）エラーの通知を**除外する**
- **通知が頻繁に来続けることを避ける**

が実現できます。

また、**Cloud Logging**（自動でエラーの分のログが記録されています）と**Cloud Monitoring**と組み合わせれば、

- **普段は対応が必要なさそうなエラーが頻発した場合にインシデントとして通知する**

も実現できます。
**例えば ポリシー "Too meny timeout" など、普段はタイムアウトは仕方ないので無視したいけど、めっちゃ多いと心配になる、という場合にも適切な通知を設定できると思います。**

## エラーの分析をする

Error Reporting ではトレースを見ることが出来ます。ここでいろいろ分析できますね。
ただし、リクエストの状態は見られれないので、そこは別の方法を検討する必要があります。

## エラーを記録する

Error Reporting の情報は同時に Cloud Logging に溜まっています。これを Cloud Storage にシンクすることで、永続的にエラーの情報を保存することが出来ます。


Google Cloud Error Reportingでエラーと上手く付き合う


> DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。ソフトウェアを迅速にビルドおよびテストする文化と環境により、確実なリリースを、以前よりも迅速に高い頻度で可能とする組織体制の構築を目指している。

[DevOps - Wikipedia](https://ja.wikipedia.org/wiki/DevOps)

> devops という用語自体は「development」（開発）と「operations」（運用）の混成後だ。だが、devops の基本概念は、組織全体に応用できるし、応用すべきものだ。成功を持続できる企業は、開発、運用チームだけから成り立っているわけではない。

[O'Reilly Japan - Effective DevOps](https://www.oreilly.co.jp/books/9784873118352/)

今回は、簡単な質問とそれに対する "devops な"組織のあり方を見ていくことにより、devops な組織がどんな組織であり、どんな組織でないか、を一緒に考えてみましょう。

## Q. 最近組織やチームの課題はなんですか？

devops な組織では特定の方法論のベストプラクティスや定義に囚われず、自分たちの課題と向き合うことができます。

_例) 開発チームとマーケティングチームの連携が取れておらず、広告経由のユーザーに対して最適なおもてなしができていないことです。_

## Q. 最近組織やチームのやり方で変えてみたことはなんですか？

devops な組織は課題と向き合い試行錯誤を行おうとします。試行錯誤を行う時間が用意されています。

_例) 最近、職種を横断した合同のミーティングを用意しました。_

## Q. メンバーの失敗・成功のストーリーを組織に共有する場所はありますか？

ストーリーを共有することで、

- チーム内の透明性が増し、チーム内に信頼が生まれます
- 実際にダメージの大きいミスをする前に、それを防ぐ方法を同僚が伝えることができます
- 新しい問題の解決に使える時間が増え、イノベーションが促進されます

_例) 私たちの開発チームは毎朝、昨日起きたことを共有するミーティングがあります。_

## Q. あるチームとほかのチームが同じコミュニケーションツールを使っていますか？

同じコミュニケーションツールを使えているということは、その 2 つのチームが互いにコミュニケーションを取ろうとしていることの結果です。コミュニケーションをしない 2 つのチームは、たとえ共通のツールとして Slack を導入したからといって、コミュニケーションをするようになる訳ではありません。

_例) 開発チームとマーケティングチームは同じ Slack のチャンネルでコミュニケーションをとっており、活発な意見交換が行われています。_

## Q. 組織の成功を測るための指標はどのくらいありますか？

成功に向けた洞察を得ることができます。

_例) 私の組織ではコンバージョン率やユーザーの行動量（PV やクリックイベントなど）を計測しています。サイトのレイテンシーを計測しています。_

## Q. 組織の成功の計測データは公開されていますか？

計測データが公開されていれば、運用について深い知識のない社員（例えばフロントエンドエンジニア）でも、反復的な改善のための知見や判断を引き出すことができます。

_例) 私の組織では、Google アナリティクスのデータは、開発チーム、マーケティングチーム、ステークホルダー、顧客に公開されています。ただし、開発チーム以外には、一部のデータのみ公開されていて、深い洞察への誘導はありません。_

## Q.　組織のルールは明示されていますか？

ルールを明示することによって、新しく参加したメンバーが組織の過去の失敗を遡ることができます。暗黙的なルールは、新しいメンバーにとって気付きにくいものであり、同じ失敗を繰り返してしまうこともあります。

_例) 私たちのチームの Wiki にはコードレビューのやり方やデプロイ後の確認事項などがまとまっています。_

---

あなたの組織の回答はどのようなものでしたか？私も自分の組織について振り返ることができました 😄

## 参考

[O'Reilly Japan - Effective DevOps](https://www.oreilly.co.jp/books/9784873118352/)


あなたの組織は"devopsな"組織ですか？


## 前提

- トランスパイラ利用の有無に関わらず、ES2017 相当の（2021/10 時点でブラウザの対応率が十分に高い）記述がユーザーのブラウザで動くようにする、という方針
- トランスパイラを用いても、**ECMAScript の全ての記述を変換してくれるわけではない**ことは薄々気づいていた
- ESLint を用いても、**ECMAScript の全ての記述を解析してくれるわけではない**ことは薄々気づいていた

## 目的

- ECMAScript を利用した場合に
  - トランスパイラは何を変換し、何を無視するのかを検証する
  - ESLint は何を解析し、何を無視するのかを検証する

## 検証用の入力

- ES6 〜 ESNext の規格に基づいたコードサンプル
  - 利用する機会がありそうな機能をピックアップ

```javascript
/**
 * ES2015
 * ------------------------------------------------
 */
/** const, let */
const cst = 1
let lt = 2
console.log(cst)
console.log(lt)

/** Allow function */
const fn = () => {
  console.log('fn')
}

/** classes */
class Hoge {
  fuga() {
    console.log('fuga')
  }
}

/**
 * ES2016
 * ------------------------------------------------
 */
/** Array.prototype.includes */
const array = [1, 2, 3, 4, 5]
console.log(array.includes(2))

/** べき乗演算子 */
console.log(2 ** 2)

/**
 * ES2017
 * ------------------------------------------------
 */
/** Async functions */
async function log() {
  console.log('hoge')
}

/** Object.values() */
const obj = { hoge: 0, fuga: 1, piyo: 2 }
console.log(Object.values(obj))

/**
 * ES2018
 * ------------------------------------------------
 */
/** Spread Properties */
const hoge = { fuga: 'piyo' }
console.log({ ...hoge })

/** RegExp named capture groups */
console.log(/(?<year>[0-9]{4})年/.test('2021年'))

/** RegExp Lookbehind Assertions */
console.log(/(?<=[0-9]+)\.[0-9]+/.test('.34'))

/**
 * ES2019
 * ------------------------------------------------
 */
/** flat array methods */
console.log([[1, 2], 3, 4].flat())

/**
 * ES2020
 * ------------------------------------------------
 */
/** Optional chaining operator */
console.log(hoge?.fuga)

/**
 * ES2021
 * ------------------------------------------------
 */
/** Logical assignment operators */
console.log((a ||= b))

/** Numeric separators */
console.log(100_000_000)

/**
 * ESNext
 * ------------------------------------------------
 */
/** static class field */
class Foo {
  static bar = 1
}

console.log(Foo.bar)
```

## 対象のトランスパイラと設定

| No  |          名前          |     ターゲット     |
| :-: | :--------------------: | :----------------: |
|  1  |  Babel / conservative  | - ( `> 1% in JP` ) |
|  2  |  Babel / progressive   | - ( `> 5% in JP` ) |
|  3  |   esbuild / default    |       ESNext       |
|  4  |  esbuild / to ES2017   |       ES2017       |
|  5  |         rollup         |   not transpile    |
|  6  | rollup-plugin-esbuild  |       ES2017       |
|  7  |  Typescript / default  |        ES3         |
|  8  | Typescript / to ES2017 |       ES2017       |

## 検証結果

### すべてのトランスパイルで変換されない記述

- RegExp named capture groups (ES2018)
- RegExp Lookbehind Assertions (ES2018)
- flat array methods (ES2019)

### ESLint で検証できない記述

- flat array methods (ES2019)
  - [freaktechnik/eslint-plugin-array-func](https://github.com/freaktechnik/eslint-plugin-array-func) を試してみたがダメ

## その他気がついたこと

- esbuild はデフォルトでコメントが削減される

## (おまけ) 実行時間

| No  |          名前          |     ターゲット     | 時間 ( s ) |
| :-: | :--------------------: | :----------------: | :--------: |
|  1  |  Babel / conservative  | - ( `> 1% in JP` ) |    0.63    |
|  2  |  Babel / progressive   | - ( `> 5% in JP` ) |    0.53    |
|  3  |   esbuild / default    |       ESNext       |    0.31    |
|  4  |  esbuild / to ES2017   |       ES2017       |    0.18    |
|  5  |         rollup         |   not transpile    |    0.20    |
|  6  | rollup-plugin-esbuild  |       ES2017       |    0.27    |
|  7  |  Typescript / default  |        ES3         |    1.21    |
|  8  | Typescript / to ES2017 |       ES2017       |    1.36    |

## 参考

- [ESLint - Pluggable JavaScript linter](https://eslint.org/)
- [Babel · The compiler for next generation JavaScript](https://babeljs.io/)
- [esbuild - An extremely fast JavaScript bundler](https://esbuild.github.io/)
- [rollup.js](https://rollupjs.org/guide/en/)
- [egoist/rollup-plugin-esbuild: Use ESBuild with Rollup to transform ESNext and TypeScript code](https://github.com/egoist/rollup-plugin-esbuild)
- [TypeScript: JavaScript With Syntax For Types.](https://www.typescriptlang.org/)
- [ES6〜ES10(es2015〜es2019)まとめ - Qiita](https://qiita.com/ozoneboy/items/9c11ac3323ca94919052)


トランスパイラとESLintは完璧じゃない


**Minimum Viable Product**の提言より、小さな製品から始めることには明確にメリットがあることが示されています。

> 誤った仮定（価値提案）に基づき多くの機能を備えた製品の開発すると、失敗した場合のコストとリスクも増加するため、MVP からインサイトを得てそれを徐々に製品開発に反映させるほうが比較的に安価である。

[実用最小限の製品 - Wikipedia](https://ja.wikipedia.org/wiki/%E5%AE%9F%E7%94%A8%E6%9C%80%E5%B0%8F%E9%99%90%E3%81%AE%E8%A3%BD%E5%93%81)

**作ってみてはじめて、それが何なのかを分かる**というのはありますよね。顧客だけではなく開発者にとっても最小限のプロダクトにはそれだけで学びがたくさんあるということです。

さらに、最近 [O'Reilly Japan - Effective DevOps](https://www.oreilly.co.jp/books/9784873118352/) を読んでいますが、ここでも組織を変えるという文脈で似たような話が出てきました。

> 組織レベルの固定思考は、改革に悪い思い出がある人やさまざまな理由でリスクを嫌う人が複数いるため発生することが多い。...間違ったドキュメントの訂正のような小さいもので良い。...そして、変更や改革は状況を改善するだけでなく、必ずしも大きな問題やサービス障害を引き起こすものでもないという自信を付けていくのである。

はい。**チーム改革がどんなものかをまず小さくやってみて確認する、フィードバックを得る**。一緒ですね。いきなり大風呂敷を広げても、チームメンバーが新しい体制への疑念を強めてしまう結果になるのはなんとなく想像できますよね。（**それ、本当にいいの？できるの？**）

これについては、私自身も最近の仕事で体験しました。**チームがユーザーがどう行動したいか、ではなく作り手がどう行動してほしいかを考えて施策を考えている**傾向があるという課題を感じていました。そこで、今の課題はこれで、ユーザビリティをこのように計測して、という話をドキュメントにまとめてみました。しかし結果は、**私自身も本当にこれで事態が解決に向かうのか？という疑念が湧いてきてしまったのです**。これはチームの体制が変わることのリスクを恐れているというのが原因だと思います。

#### どうするべきか？

うーん。この場合どうするべきでしょうか？明日のミーティングでは**私が**ユーザーがどう行動したいか、を軸とした施策を提案するところから始めてみようと思いました。その案が上手く行けば、次も似た考え方に基づいた施策を考えやすいのではないでしょうか。

この辺りで、**サイズを小さくはじめることは仕事のやり方にも通用するのでは？** ということに気が付きました。そこで私なりのルールを作りました。

1. **自分から**はじめる
2. **自分の仕事の領域から**はじめる
3. **シンプルなプロダクトから**はじめる
4. **すぐにフィードバックが得られるところ**からはじめる

以上です。


小さなプロダクトから、小さな仕事から


クリーンアーキテクチャですが、[hanami/hanami: The web, with simplicity.](https://github.com/hanami/hanami) と出会ってから 5 周回くらいして、ようやく腹落ちしつつあるのでまとめてみます。

#### フレームワークを利用しつつ理解するのは難しい

フレームワークを利用した場合、例の図の Usecase の外堀をグルッと埋める形になります。MVC なら Controller、View、Model です。Hanami の場合は Repository が来ます。個人的にはこの内側から 3 層目が全て一体化していると、どうしてもそれらが中心であるように感じてしまうんですよね。

そこでアプリケーションのそれぞれの責務を別のライブラリを利用して実装することを試してみました。

これです。 [cc-kawakami/clean-architecture-minimal-app: A minimal Clean Architecture app](https://github.com/cc-kawakami/clean-architecture-minimal-app)

利用したライブラリはこれらです。

- Usecase: [utils/interactor.rb at v1.3.8 · hanami/utils](https://github.com/hanami/utils/blob/v1.3.8/lib/hanami/interactor.rb)
- Controller: [sinatra/sinatra: Classy web-development dressed in a DSL (official / canonical repo)](https://github.com/sinatra/sinatra)
- Serializer: [procore/blueprinter: Simple, Fast, and Declarative Serialization Library for Ruby](https://github.com/procore/blueprinter)
- Object Mapper: [rom-rb/rom: Data mapping and persistence toolkit for Ruby](https://github.com/rom-rb/rom)
- DB: [sparklemotion/sqlite3-ruby: Ruby bindings for the SQLite3 embedded database](https://github.com/sparklemotion/sqlite3-ruby)

#### 「Entity あれ。」

アーキテクチャの中心から攻めていきます。まずは Entity。

```ruby
class User
  attr_reader :id, :name, :email

  def initialize(id:, name:, email:)
    @id = id
    @name = name
    @email = email
  end
end
```

普通のクラスですね。ビジネス上でどんな情報を扱うかを定義しています。今回はユーザーを管理することを想定して User entitiy を用意しました。

#### 次にアプリのビジネスロジック

このアプリではユーザーを ID で検索できるようにします。

```ruby
class FindUser
  include Hanami::Interactor

  expose :user

  def initialize(repository:, serializer:)
    @repository = repository
    @serializer = serializer
  end

  def call(id)
    begin
      #ユーザーを探す
    rescue => e
      error!(e.class.name)
    end
  end
end
```

こんな感じの Usecase を用意しました。これがアプリがビジネス上のどんな目的を果たすかを定義できました。Repository, Serializer は Entity をとってくるところと出力するところの Adapter ですね。これを Usecase が利用します。

#### あとは Adapter を拵えていく

Repository。

```ruby
class UserRepository < ROM::Repository[:users]
  commands :create

  def find(id)
    users.by_pk(id).map_to(User).one
  end
end
```

Controller。

```ruby
get "/users/:id" do
  find = FindUser.new.call(params["id"])

  if find.success?
    if find.user
      status 200
      body = find.user
    else
      status 404
      body = { error: "Not found!" }
    end
  else
    status 500
    body = { error: find.error }
  end

  json body
end
```

Serializer です。

```ruby
class UserSerializer < Blueprinter::Base
  identifier :id

  fields :name, :email
end
```

これで揃いました。

あとは、さっき出てきた Usecase の詳細な記述をしていきます。

```ruby
class FindUser
  include Hanami::Interactor

  expose :user

  def initialize(
    repository: UserRepository.new(App.new.rom),
    serializer: UserSerializer
  )
    @repository = repository
    @serializer = serializer
  end

  def call(id)
    begin
      user = @repository.find(id)
      @user = @serializer.render_as_hash(user)
    rescue => e
      error!(e.class.name)
    end
  end
end
```

#### 実行する

```bash
$ curl http://127.0.0.1:9292/users/1
{"id":1,"email":"smith@exmaple.com","name":"Smith"}
```

OK。ここまでの流れで、HTTP リクエスト・レスポンスは、FindUser のビジネスロジックの**入出力の詳細の一つ**に過ぎないことが体感できましたでしょうか。
同じ様に、DB は User を生成するための**実装の一つ**でしかありません。**DB や HTTP は詳細**なのです。

#### 責務を混ぜることが難しい = 責務が混ざらない

この設計なら、Controller に Entity の検索が記述されることは、よほど工夫しない限り起こらないということが分かるでしょう。DB や HTTP、HTML、JSON の詳細は Usecase を起点として、円のそれぞれの方向へ分散される、という設計に自然と誘導されます。

以上です。ありがとうございました。


Rubyの小さなライブラリ群によるアプリでクリーンアーキテクチャを理解する


マルチステージビルドの背景にはイメージサイズの削減があります。

> イメージをビルドする際に取り組むことといえば、ほとんどがそのイメージサイズを小さく抑えることです。 Dockerfile 内の各命令は、イメージに対してレイヤーを追加します。 そこで次のレイヤー処理に入る前には、不要となった生成物はクリーンアップしておくことが必要です。 現実に効果的な Dockerfile を書くためには、いつもながらトリッキーなシェルのテクニックや、レイヤーができる限り小さくなるようなロジックを考えたりすることが必要でした。 つまり各レイヤーは、それ以前のレイヤーから受け継ぐべき生成物のみを持ち、他のものは一切持たないようにすることが必要であったわけです。

[マルチステージビルドの利用 — Docker-docs-ja 19.03 ドキュメント](https://docs.docker.jp/engine/userguide/eng-image/multistage-build.html)

ただ、私の場合は、イメージサイズよりもその**ビルド時間の大きさの方**が深刻です。
なぜなら、私がよく使う言語は**スクリプト言語**だからです。

ところが、このマルチステージビルド、うまく利用すればかなりビルド時間の短縮を実現することができるようです。

やってみましょう。簡単な Ruby on Rails と Node.js によるアセット環境を例に、まずはシングルステージの場合から初めて、そこから改善を試みていきます。

```Dockerfile
FROM ruby:3.1
RUN curl -fsSL https://deb.nodesource.com/setup_16.x | bash - && apt-get install -y nodejs
RUN npm install --global yarn@1.22.19
RUN gem install bundler
RUN mkdir -p /rails
WORKDIR /rails
COPY . .
RUN bundle install
RUN yarn install
RUN RAILS_ENV=production bundle exec rails assets:precompile
CMD ["bin/rails", "s"]
```

最後に怒涛の

```Dockerfile
RUN bundle install
RUN yarn install
RUN RAILS_ENV=production bundle exec rails assets:precompile
```

が行われていますが、ほとんどの場合最も時間がかかるのはここです。
さらに厄介なのは、ソースのいずれかが変更された場合、

```Dockerfile
COPY . .
```

のレイヤーキャッシュが崩れるので、必ず

```Dockerfile
RUN bundle install
RUN yarn install
RUN RAILS_ENV=production bundle exec rails assets:precompile
```

が実行されます。
これはレイヤーキャッシュの仕組みにより必ずそのようになるのです。

> キャッシュが無効になると、次に続く Dockerfile コマンドは新たなイメージを生成し、キャッシュを使いません。

[Dockerfile のベスト・プラクティス — Docker-docs-ja 20.10 ドキュメント](https://docs.docker.jp/develop/develop-images/dockerfile_best-practices.html#add-copy)

この問題を解決するために、次は `builder` ステージを用意してみます。

```Dockerfile
FROM ruby:3.1 as builder
WORKDIR /tmp
RUN curl -fsSL https://deb.nodesource.com/setup_16.x | bash - && apt-get install -y nodejs
RUN npm install --global yarn@1.22.19
RUN gem install bundler
COPY Gemfile Gemfile.lock ./
RUN bundle install
COPY package.json yarn.lock ./
RUN yarn install
COPY app/assets app/assets
COPY app/javascript app/javascript
COPY bin bin
COPY config config
COPY Rakefile vite.config.ts ./
RUN RAILS_ENV=production bundle exec rails assets:precompile

FROM ruby:3.1 as app
RUN mkdir -p /rails
WORKDIR /rails
COPY --from=builder /usr/local/bundle /usr/local/bundle
COPY --from=builder /tmp/public/vite public/vite
COPY . .
CMD ["bin/rails", "s"]
```

注目すべきは、ここです。

```Dockerfile
COPY --from=builder /usr/local/bundle /usr/local/bundle
COPY --from=builder /tmp/public/vite public/vite
COPY . .
```

`--from` では他のステージからファイルをコピーすることができますが、**問題は `COPY` の順番**です。
まず、時間のかかる可能性が高い、

```Dockerfile
COPY --from=builder /usr/local/bundle /usr/local/bundle
COPY --from=builder /tmp/public/vite public/vite
```

が先に記述され、その後

```Dockerfile
COPY . .
```

が実行されます。これで、`Gemfile` `Gemfile.lock` のいずれかが変更されない限り、`bundle install` は実行されません。

ただ、問題は残されていて、
`Gemfile` `Gemfile.lock` のいずれかを変更してしまうと、`yarn install` まで実行されてしまいます。

では、ここで今の所の最終形態に行っていましょう。

```Dockerfile
FROM ruby:3.1 as builder
RUN curl -fsSL https://deb.nodesource.com/setup_16.x | bash - && apt-get install -y nodejs
RUN npm install --global yarn@1.22.19

FROM ruby:3.1 as bundler
WORKDIR /tmp
RUN gem install bundler
COPY Gemfile Gemfile.lock ./
RUN bundle install

FROM node as yarn
WORKDIR /tmp
COPY package.json yarn.lock ./
RUN yarn install

FROM builder as assets
WORKDIR /tmp
COPY --from=bundler /usr/local/bundle /usr/local/bundle
COPY --from=yarn /tmp/node_modules node_modules
COPY app/assets app/assets
COPY app/javascript app/javascript
COPY bin bin
COPY config config
COPY Rakefile Gemfile Gemfile.lock package.json yarn.lock vite.config.ts ./
RUN RAILS_ENV=production bundle exec rails assets:precompile

FROM ruby:3.1 as app
RUN mkdir -p /rails
WORKDIR /rails
COPY --from=bundler /usr/local/bundle /usr/local/bundle
COPY --from=assets /tmp/public/vite public/vite
COPY . .
CMD ["bin/rails", "s"]
```

👍

この `Dockerfile` では、

- **実行プロセスが依存しているファイルの変更のみを捕捉し、キャッシュを制御している**

を実現しています。これで、例えば `Gemfile.lock` が変更されても `yarn install` は実行されることはありません。

**さらに**

**`yarn` ステージと `bundler` ステージは、並列処理される**ことにお気づきでしょうか。

実行の構造としては、

- `COPY --from=bundler /usr/local/bundle /usr/local/bundle`
  - `RUN bundle install`
- `COPY --from=bundler /usr/local/bundle /usr/local/bundle`
  - `--from=yarn /tmp/node_modules node_modules`
    - `RUN yarn install`

となり、`--from` を解決しつつ、必要な処理を並列で実行することができるようになりました！

以上。

- **マルチステージビルドで、レイヤーキャッシュを最大限に活かすことができる**
- **マルチステージビルドで、並列処理を実現できる**

でした。


Dockerのマルチステージビルドを利用してビルド時間を短縮する


**Sass の問題点ははっきりしていました**。同時に、**CSS の新しい仕様たちは非常に明快**で注目に値するものでした。この辺りを踏まえて純 CSS へ戻ろうとしましたが、結果的に踏みとどまったので、その辺りの経緯をまとめます。

## 🙋‍♀️ そもそも我々は Sass をなぜ使っているのか？

個人的に、チーム的にこんな感じでした。この辺りは人それぞれあると思います。

1. クラス名を付けずにタグに対してスタイルを指定したいときにスタイル規則を**ネスト**したい
2. ソースコードの視認性を高めるためにコンテンツのセクションごとにスタイル規則を**ネスト**したい
3. 検索性を高めるために目的別・コンテンツ別に**ファイルを別けたい**
4. 大規模なプロジェクトでは**色のパターンを定義して再利用したい**
5. メディアクエリの**画面幅の数値を定義して再利用したい**
6. 大型のプロジェクトでは`@extend`を利用して**スタイルを共通化**している
7. 一部のプロジェクトでは`@mixin`を利用して**ベンダープレフィクスを共通化**（最近は autoprefixer を使っているが）したり、**スタイル規則を定義**したり、**ブレイクポイントを共通化**したりしている

## 🤷‍♀️ Sass の何が困っているか？

### 1. 全ての機能がプリセットされている

**利用していない機能もプリセットされている**。チームとして、どの機能を使っていきたいか、の基準を明確化しなければ、**新規参画したメンバーは片っ端から機能を使い倒し**、レビューが辛くなる可能性が高い。

### 2. 言語の実装が複数あったが廃止されているので移行対応が必要

- [Sass: LibSass is Deprecated](https://sass-lang.com/blog/libsass-is-deprecated)
- [Sass: Ruby Sass Has Reached End-Of-Life](https://sass-lang.com/blog/ruby-sass-is-unsupported)

Dart Sass に加えて、[Sass: Embedded Sass is Live](https://sass-lang.com/blog/embedded-sass-is-live)も出てきました。

### 3. 本質的に使用の方針が不安定になる傾向がある

**Sass はリアルワールドで便利とされている CSS 設計理論に合わせて、仕様を変化させるような、現実的な方針をとっています**。以下の機能は現在進行形で廃止に向かっているので、過去のコードを変更する必要があります。

#### `@import`

`@import`だと階層的に`@import`を利用している場合でもスタイル規約にアクセスできるますが、この仕様が問題視されはじめ、代替案として`@use`が採用されました。これは呼び出したファイルでしかスタイル規約にアクセスできないようになります。

[Sass: @import](https://sass-lang.com/documentation/at-rules/import)

### 4. CSS 本体の仕様とコンフリクトする可能性がある

#### `/`を利用した除算

CSS では`/`を区切り文字とするプロパティがあります。
この時に Sass からしてみれば、その`/`が区切り文字なのか、除算なのか区別がつかなくなってしまいます。これの代替案として`Math.div`を推奨しています。

[Sass: Breaking Change: Slash as Division](https://sass-lang.com/documentation/breaking-changes/slash-div)

## 🤔 ところで CSS の動向は？

[cssdb - CSS Database](https://cssdb.org/) では**stage と呼ばれる、新しい機能の標準化への段階**を定義しています。

| Stage  |         Level          | 成熟レベル |
| :----: | :--------------------: | :--------: |
| Stage4 | Standardized（標準化） |     高     |
| Stage3 |    Embraced（包容）    |     :      |
| Stage2 |   Allowable（許容）    |     :      |
| Stage1 | Experimental（実験的） |     :      |
| Stage0 | Aspirational（野心的） |     低     |

Stage が上がるにつれて、実際にブラウザの対応状況も良くなっていっているようですね。
また、[postcss-plugins/plugin-packs/postcss-preset-env](https://github.com/csstools/postcss-plugins/tree/main/plugin-packs/postcss-preset-env)ではこの stage に準拠して、将来的に標準化されるであろう機能を利用することができます。

Sass でよく使っていたような機能も結構出てきているみたいですね。

| 実現したいこと         | CSS                          | PostCSS プラグイン            |
| ---------------------- | ---------------------------- | ----------------------------- |
| ネスト                 | nesting rule (stage 1)       | postcss-nesting               |
| ファイル分割           | -                            | postcss-import                |
| 色の再利用             | custom property (stage 3)    | postcss-custom-property       |
| メディアクエリの再利用 | custom media query (stage 2) | postcss-custom-media          |
| クラス継承             | 議論中                       | postcss-extend                |
| Mixin                  | 議論中 [^1]                  | postcss-mixins, postcss-apply |

[^1]: `@apply`が議論されているが、技術的な課題があって難航しているらしい

それぞれのルールの記法については、色々調べてみてください。

### Mixin の用途別の再現方法

- 共通のスタイル規則を定義 => シングルクラスを採用しない
- ベンダープレフィクスの共通化 => Autoprefixer
- ブレイクポイントの共通化 => CSS の custom media query

## 🫣 stage が低いルールの仕様はとても不安定

W3C で定義されている stage は、正式なリリースバージョンではなく、その使用の安定性は低いです。
**stage が低いものは、仕様が変更されたり、reject される可能性が高いことも考慮しなければならない**。
CSS の草案に対しての知識や経験がほとんどないうちには、postcss-preset-env のデフォルト（stage 2）に従った方がいいと思われます。

例えば、nesting rule はまだ stage 1 なので、仕様が変更される可能性が高いです。**もし postcss-preset-env で実装しても、もしかすると nesting の部分だけあとで実装し直す必要があるかもしれませんね**。

## 😌 postcss-preset-env の採用はまだ早いかも

上の話でやっぱり postcss-preset-env の採用はまだ早いかもしれません。
今後は、

- **CanIUse などを使ってブラウザの対応状況を見ていく**
- **もし使いたい機能の stage が 4 になり、ブラウザ対応が十分になれば採用する**
- **autprexier のように、CSS 本体とは別なアプローチのために PostCSS は採用を進めていく**

かなと思いました。ありがとうございました。


Sassから純CSSの世界へ戻ろうとして踏みとどまった話


Dependabot 溜めてました。

反省して、Dependabot を活用するため色々試してみたので、それについてまとめます。

## 1. Dependabot 用の時間を作る

月の初めに Dependabot のマージに取り組む、と決めてしまいました。

## 2. レビュアー・マイルストーンの自動設定

レビュアーに自分が設定されているとレビューしなきゃってなりますよね。
マイルストーンに日付が設定されていると時間内にやろうって気になりますよね。多分。

ということで以下のように設定しました。

| 項目           | 値                                    |
| -------------- | ------------------------------------- |
| レビュアー     | 全員                                  |
| マイルストーン | `security-update-<month>` (毎月 8 日) |

意識したのは、レビュアーを最大限に設定することです。**人の目は出来るだけ増やすという方針を明示しました**。ただし、チームの体質によっては、レビューがお見合いになる可能性はあります。

また、自動設定の方法は、リポジトリごとに Github Actions を設定するのが大変だったので、Dependabot 対策用のリポジトリを一つ作ってそこから、API を叩いて設定することにしました。

## 3. TODO リストを作る

その月に取り組む Dependabot の PR を Issue に TODO リストとしてまとめるようにしました。これによって、**全体像が把握でき、振り返りをしやすくなる**のではという算段です。

## 4. ルールを明言する

Dependabot をチームで取り組むために統一されたルールを用意しました。

- Dependabot には**メジャーバージョン**のアップデートも含まれることに注意する
  - ほとんどのライブラリは最新のメジャーバージョンでセキュリティアップデートを行なっています
- メジャーバージョン・マイナーバージョンは**テスト**を実行する
- パッチバージョンは**リリースノート**を確認する
- 以前アップデートにより不具合が起きたものは、**注意するリストに記録**しておく

## 5. Dependabot の PR の量を必要最小限にする

静的サイトジェネレータに関するライブラリは、**ユーザーの入力を受けないので**、リスクが低いと判断して、今回はスキップしました。

---

以上、取り組みでした。今後の課題としては、

- アップデートされるバージョンの種類によって CI の実行内容を変えたい
- たくさんレビューしたで賞を設けたい

です。ありがとうございました。


Dependabot をちゃんと活用するために行なった取り組み


こちらです。[cc-kawakami/shufu: Shufu is a simple Command as Code](https://github.com/cc-kawakami/shufu)

コマンドの引数やオプションの構成を定義しておいておきたい時があって、そのときに書いた気がします。
たしか、`gcloud` コマンドを YAML として定義することで、簡易的な Infrastructure as Code を実現しようとしたときに導出しました。

詳しく見ていきましょう。

基本はこうです。

```ruby
require "shufu"

# コマンドのスキーマの定義
schema = {
  git: {
    commit: {
      amend: :flag,
      author: :equal
    }
  }
}

# スキーマからコマンドのオブジェクトを生成
command = Shufu::Command.new(schema)

# to_s にスキーマに対応した値を渡すことで string になります！
p command.to_s({ amend: true, author: "cc-kawakami" })

# => "git commit --amend --author=cc-kawakami"
```

ここから発展して、例えば、`gcloud alpha storage buckets create` コマンドのスキーマを定義して、

```yaml
gcloud:
  alpha:
    storage:
      buckets:
        create:
          name: :param
          class: :equal
          bucket-level: :equal
          location: :equal
```

それに対する値も定義しておいて、

```yaml
name: foobarbox
class: regional
bucket-level: 'on'
location: us-central1
```

Shufu を使ってください。

```ruby
schema = YAML.load_file(schema_filepath)
values = YAML.load_file(value_filepath).map { |k, v| [k.to_sym, v] }.to_h
Shufu::Command.new(schema).to_s(values)
```

そうすれば、簡易的な IaC の完成です！


Rubyで"Command as Code"を実装してみた


Vite は、`postcss-import` を利用して `@import` を実現しています。

[Features | Vite](https://vitejs.dev/guide/features.html#css)

例えば以下のようなコードがあるとします。

```
src/
  ├── img/
  │    └── about-mainvisual.png
  └── css/
       ├── application.css
       └── pages/
             └── about.css
```

```css:src/css/application.css
@import "./pages/about.css"

main {
  background-color: white;
}
```

```css:src/css/pages/about.css
.about__mainvisual {
  background-image: url(../../img/about-mainvisual.png);
}
```

**これだと上手くいきません。**

1. `@import` の解決
2. `url()` の解決

の順に Vite は処理します。

つまり、1 の時点で

```css:src/css/application.css
.about_mainvisual {
  background-image: url(../../img/about-mainvisual.png);
}

main {
  background-color: white;
}
```

という CSS が一時的に生成されているのと同義であると言えます。
だから、`url(../../img/about-mainvisual.png)` のパスが間違っていると言えるのです。

どうしたらいいのでしょう？
正解は、

```diff css:src/css/pages/about.css
.about__mainvisual {
-  background-image: url(../../img/about-mainvisual.png);
+  background-image: url(/img/about-mainvisual.png);
}
```

**絶対パスで指定してください。そうすれば、画像の参照元に依存せずに解決することができます。
ここで、Vite の `root` 設定が `src` になっていることが前提です。**


ViteでCSSから画像を参照する


## 対象者

- サイトの設計に関わる人
- 具体的な計測方法などについて深く掘り下げるかはまだ未定です（技術者向けの内容になるかも）

## 想定する課題

- ユーザーにとって嬉しいコンテンツと使いやすい機能を定義できていない
  - 「嬉しい」「使いやすい」の基準が分からない
- ユーザーのタスクの完了率を最大化する設計ができていない
  - タスクとして、PV しか定義できていない
  - 完了率として、PV しか計測できていない

## ユーザーにとって「嬉しい」「使いやすい」を定義する

一般的にユーザビリティの高いタスクは以下のような指標において優秀な成績を収めているとされています。ここでタスクとは、コンテンツ読了、機能利用などユーザーが目標に到達するために行う行動を指します。

- _Task success rate（タスクの完了率）_
- _Time on task（タスクにかかった時間）_
- _Use of search vs. navigation（検索の利用率）_

see [5 UX KPIs You Need To Track - Every Interaction](https://www.everyinteraction.com/articles/5-ux-kpis-need-track/)

## 目標到達プロセスを設定する

目標達成プロセスは、いくつかのステップによって構成され、ユーザーにどのようにサイトを使ってもらいたいかを定義します。各ステップがタスクとなりますが、目標達成も大きなタスクと言うことができます。

### より詳細にサイトを設計するためのプロセス

ステップはできるだけ詳細に定義してください。PV ではなく行動を単位として考えることで、サイト構成だけでなく、ページ内のコンテンツ・機能について議論することができるようになります。

- _Bad：ページビューをステップとする_
- _Good：検索フォームの項目入力をステップとする_

GA4 を利用している場合には、このステップは、PV だけではなく、あらゆるイベント、たとえばスクロールやクリックとして定義できます。ステップとして利用したいイベントを取得するための方法は後述します。

### 目標達成プロセスは複数存在してよいか？

目標達成プロセスが一通りであるサイトの方が少ないでしょう。ユーザーの趣向や時期、広告などによってプロセスは変わることがあります。その場合は、ユーザータイプの定義や経路の定義を行い、それに対応したプロセスを設定してください。

## ステップに従ってページを設計

ユーザーに期待するステップを元に、ページ構成・サイト構成を設計してください。
プロセスが複数ある場合は、そのすべてを満たすような設計にする必要があります。プロセスのバッティングが起きた場合には、優先度の高い方にとって効果的な設計を採用してください。
これを実践すると、プロセスに影響を与えないコンテンツは必要のないコンテンツということができてしまいます。しかし、ユーザーの行動パターンをすべて網羅することは不可能ですから、完璧を目指す必要はありません。ただし、コンテンツを追加する場合には、本当に目標達成にとって効果的なものなのか？という問いを忘れないようにしてください。

また、

- _Time on task（タスクにかかった時間）_
- _Use of search vs. navigation（検索の利用率）_

の指標に則って、

- ステップ数を最小限にする
- 入力はできるだけ補完する
- 検索ではなくリンクを用意する

などを意識してください。

## ステップの成功率を計測する

実践として基本は GA4 の「探索」の「目標達成プロセス」を利用してください。
ここでは、

- 各ステップを定義できる
- ステップの完了率/放棄率を見られる

を実現することができます。

また、タグマネージャと GA4 を組み合わせて以下のようなイベントを計測することができます。

- すべての要素のクリックイベント
  - HTML 要素
  - テキスト
  - フォームの値
  - リンク先
- スクロール率
- ある要素の表示

## ステップの成功率を向上させる

各ステップの成功率を向上させるような施策を検討してください。特に成功率の低いステップに重点を置いたり、施策のしやすいところから始めたりすると、何から手を付けてよいか迷うことが少なくなります。

## プロセス変更の検討

どうしても、ステップの成功率を向上させることが難しいと判断した場合には、プロセスの変更を検討してください。

## 参考

- [5 UX KPIs You Need To Track - Every Interaction](https://www.everyinteraction.com/articles/5-ux-kpis-need-track/)
- [ユーザーがより「頑張らなくていい」体験を考える | UX MILK](https://uxmilk.jp/82642)


「嬉しい」「使いやすい」を最大化するサイト設計


例えば、タグマネージャのスニペットを本番環境に加えて、その他の環境にもテスト用のものを埋め込みたいような場合があるとします。

過去の私は以下のように実装していました。

```erb
<% if Rails.env.production? %>
  <%# 本番用のスニペット %>
<% else %>
  <%# その他の環境用のスニペット %>
<% end %>
```

うーん。これには問題がありました。

- 👎 本番環境にデプロイするまで if 文の検証ができない
- 👎 `RAILS_ENV=production` で確認できるとしても、そのほかの場所にどんな影響があるかわからない

代わりに、環境変数を利用してみるとどうでしょうか。

```erb
<%= sanitize ENV[:GTM_HEAD_SNIPPET] %>
```

いいかも！
