2024年4月1日より、障害者差別解消法の改正内容が適用され、障害がある方への「合理的配慮」が義務付けられました。これまでは、国や地方公共団体などに義務付けられていましたが、その適用範囲が拡張され、民間事業者に対しても適用されます。  
  
合理的配慮とは、例えば、  
  
・車いすの利用者が移動しやすいように手伝う。スロープを設置する。  
・窓口で、手話や筆談で意思の疎通をする。  
  
などが該当します。  
  
社会生活の中にある障壁を取り除き、全ての人が利用しやすいバリアフリーな環境を実現するため、負担が重すぎない範囲で対応することが努力義務となりました。これは接客業を行う事業者に限定された話ではありません。スターフィールドのようにWeb制作を行う事業者も対応が必要となります。  
  
Webサイト制作においては、「Webアクセシビリティを確保した開発」が求められます。  
  
##bアクセシビリティとは
  
Webアクセシビリティとは、すべての人がWebサイトにアクセスしやすく不自由なく使える状態を指します。そしてなるべく向上させていくことを理想としています。  
  
一般的に、Webアクセシビリティが確保できているとは、以下の状態を指します。  
  
・視覚障害あっても情報が伝わり、操作もできること。  
・キーボードだけで操作できること。  
・一部の色が区別できなくても得られる情報に欠損が無い事。  
・音声コンテンツや動画コンテンツを設置したさい、音声が聞こえなくても情報が分かること。  
  
もはやインターネットは情報インフラとして社会に欠かせない物となり、あらゆる方が使用します。もちろん五体満足の健常者だけでなく、高齢者や、視覚障害や聴覚障害などの障害者なども利用します。  
特に障害者に関しては、症状や程度は人それぞれです。そういった個々の状況に応じた対応が求められます。障害者に限定しなくても怪我や病気で一時的ハンデを負う人、加齢により視力の衰えが有る方も利用しやすい環境整備が必要です。  
  
こういったすべての人々がWebサイトを不自由なく利用できるようにすることが、ウェブアクセシビリティの要件です。なので、どんな事情がある方でも利用しやすい環境を提供することが、企業の社会的な責任として求められます。

また、この対応をすることは障害者のために負担を強いられる作業ではなく、使いやすい便利なWebサイトを開発することでもあり健常者にとっても有益なことです。
  

 ![](https://cont.sterfield.co.jp/uploads/photo1_76ee39cc16.jpg) 



## 実践プロセス
  
実際にどういう点に気を付けてコンテンツ制作をするべきか、政府広報オンラインや、デジタル庁のWebアクセシビリティ導入ガイドブックなどでも案内されていますので、紹介します。  
  
### 音声を自動再生させない
  
音声を自動再生することや強制的に再生させることは避けるべきです。もし、自動再生するのなら3秒以内に収め、3秒以上続く場合は利用者が止められるようにする必要があります。  
また、音声の流れるページや動画広告などで自動再生する場合は、一時停止またはミュートボタンを設置するべきです。  
  
### ポップアップなどモーダルウィンドーには終了ボタンをつける
  
Webサイトはマウス操作が難しい場合はキーボードだけで利用する方もいます。その際、モーダルウィンドーを開いた際、モーダルウィンドウを閉じるボタンがないとキーボードの操作だけではモーダルウィンドウからの離脱ができません。  

### 1秒に3回以上光が点滅するコンテンツは作らない
  
高速で光の点滅を繰り返すコンテンツは光感受性発作などを発生する恐れがあります。時には重大な健康被害が出ることもあります。  
アニメーションを制作するならその危険性も十分知っておくべきです。

### 自動でコンテンツを切り替えない
  
情報を受け取れる速度は人によって異なります。また、画面上に動き続けるコンテンツがあると、他の箇所の操作や閲覧を妨げられる利用者もいます。そのため、スライドショーなど、自動で切り替わるコンテンツなどがある場合は、一時停止、非表示、停止の機能を設置する必要があります。

### ロゴ・写真・イラストなどの画像が指し示している情報を代替テキストとして付与する

画像を使用する際はalt属性を設置して代替テキストの設置が必要です。代替テキスト」は画像で提供される情報に対して「同等の役割を果たすテキスト」のことで、画像の変わりにこのテキストが表示されても違和感がないことが望まれます。  
  
具体的には、以下になります。  
  
・画像がリンクの場合、代替テキストはリンク先を示す内容であるべき。  
・グラフや図表はその要約を記述するべき。但し、隣接するテキストに要約があるのなら、何のグラフや図表を示すだけでよい。  
・文字や（ロゴマークや見出しなど）を表現している場合、同じ文字を記述するべき  
・装飾など意味がない画像については空のaltを設置するべき  
  
また、文字数については制限がありませんが、スクリーンリーダなどで音声出力されることを考慮すると80字ほどを目安にするべきです。
  
### キーボード操作だけで、サービスのすべての機能にアクセスすることができるようにする

マウス操作が難しい人はキーボードの操作に頼らず負えません。  
そのため、フォーカスインジケーター（選択中の要素に枠線）をつけるなどキーボード操作前提の作り方をするべきです。

### 色の違いだけで情報を伝えるのやめる
  
色覚に異常があり、正常に色が見えない人がいます。他えば赤色が分からない人が下記図を見ると全てが黒一色に見えてしまいます。


 ![](https://cont.sterfield.co.jp/uploads/sample1_f3f00e436c.png) 

  
このようなデザインでは必須項目が分かりません。  
  
### テキストはスクリーンリーダで音声として出力されることを意識する
  
視覚障害がある方、テストはスクリーンリーダなどを使ってテキストを音声として出力します。  
  
下記図の「日時」と「場所」の表記について、左側の方では、「日　時」「場　所」とスペースが空いています。スペースは全角のスペースを入力して作りました。  
  
 ![](https://cont.sterfield.co.jp/uploads/sample2_dfae820b43.png) 
  

この場合、スクリーンリーダで読んでみると、「ひ　とき」「ば　ところ」と呼んでしまいいます。  
  
もし、このようにスペースを空けるデザインをするなら、CSSを用いて広げないとスクリーンリーダが正しく読み取れません。
  
### リンク先を明確にする
  
リンクでどこか他のページへ移動する際どんなページへ移動するか明確にするべきです。例えば、以下のようなコンテンツの場合、左側のリンクは「詳しくはこちら」とだけ書いてあり、このボタン単体では移動先がどのようなコンテンツか分かりません。  
  

 ![](https://cont.sterfield.co.jp/uploads/sample3a_e9c460827b.png) 

  
視覚情報を使える人なら、テキストに付随したものと判断できるでしょうが、音声情報だけであったり、点字ディスプレイではその前後関係の把握が分かりにくい可能性があるのでリンクだけでどこに移動するか明確にした方がいいです。  
  
  
など、多くの事例があります。  
  
また、肝心なことはプロジェクトを進めるに辺り、一人担当者を決めて対応するのではなく、プロジェクトに関わる全員が対応策を検討し、メンバー全員でどんな対策を検討するべきか検討することが重要です。基本的には、JIS X 8341-3:2016などのガイドラインを参考にして開発を行い、チェックツールで確認しながら、向上させていくのが一般的ですが、結局のところ、最適解は人間が判断して決めなくてはいけないからです。  
  
例えば、画像には代替えテキストを設置するべき点を例にすると、ガイドラインでも示しているし、もし抜けがあったらチェックツールで指摘してくれます。なので、設置漏れは防げますが、どんな代替えテキストが適切かはコンテンツによって異なります。  
仮に犬と猫が映っている写真があったとします。これに入れる代替テキストは「犬の写真」或いは「猫の写真」とした方がいいのか、「動物の写真」とした方がいいのか、これはコンテンツ次第です。この判断は人間にしかできません。  
  
## まとめ
  
今回ガイドラインを見て指摘している点は、普段の業務で「既にやっている」あるいは、「できればやった方がいい」と言われている物が多かったのですが、強く意識していない点でもありました。  
しかし、より良い物を作る上ではしっかり意識しなくてはいけないなと思いました。今後はガイドラインを参考にしてより良いサービスを提供できるようにつ努めていきます。
  
#### 参考記事
  
政府広報オンライン：  
https://www.gov-online.go.jp/useful/article/202310/2.html#c1
  
  
デジタル庁　Webアクセシビリティ導入ガイドブック  
https://www.gov-online.go.jp/useful/article/202310/2.html#c1


240419_mv.jpg

Webアクセシビリティの義務化について調べてみました

## はじめに

Prisma でデータベーススキーマを書く際に、[ZenStack](https://zenstack.dev/) というフレームワークが便利だったので紹介します。
ZenStack にはさまざまな機能がありますが、今回はデータベーススキーマの定義について重点的に説明します。

## ZenStack とは

ZenStack は、Node.js と TypeScript 向けのフルスタック開発フレームワークです。データベーススキーマを定義するだけで、フロントエンドとバックエンドの実装を自動的に生成できます。
ZenStack は、Prisma ORM をベースとして構築されているので、Prisma のすべての機能を利用できます。

## ZenStack を使用したデータベーススキーマの書き方

ZenStack では、[ZModel](https://zenstack.dev/docs/reference/zmodel-language) というデータモデリング言語でデータベーススキーマを作成します。
[Prisma Schema](https://www.prisma.io/docs/orm/prisma-schema) をベースとしているので、基本的な文法は Prisma Schema と同じように書くことができます。

また、VSCode 向けに[ZenStack の拡張機能](https://marketplace.visualstudio.com/items?itemName=ZenStack.ZenStack)が用意されています。
エラーチェックやコード補完をしてくれるので、ZModel でデータベーススキーマを書く際はインストールしておくと便利です。

## ZModel を Prisma Schema に変換する方法

ZModel で定義したデータベーススキーマを Prisma で使用するには、以下のコマンドで ZModel → Prisma Schema に変換する必要があります。

```
npx zenstack generate
```

変換元と変換先のファイルパスを指定したい場合は package.json に以下の設定を記述します。

```
  "zenstack": {
    "schema": "[変換元のZModelファイル(デフォルト：./schema.zmodel)]"
    "prisma": "[変換先のSchemaファイル(デフォルト：./prisma/schema.prisma)]",
  },
```

## ZModel の便利機能

Zmodel で利用できる便利な機能をいくつか紹介します。

### abstract

ベースとなる抽象化 model を作成し、各項目を継承できます。
登録日時などのように、各テーブルに共通なフィールドがある場合に使うと便利です。

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

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

abstract model Base {
  id Int @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

model User extends Base {
  email String @unique
  name String
  posts Post[]
}

model Post extends Base {
  title     String
  content   String?
  published Boolean @default(false)
  author    User? @relation(fields:  [authorId], references: [id])
  authorId  Int?
}
```

上記 ZModel を変換すると、以下のような Prisma Schema が生成されます。

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

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

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

model Post {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    title String
    content String?
    published Boolean @default(false)
    author User? @relation(fields: [authorId], references: [id])
    authorId Int?
}
```

### ファイル分割

1 ファイルで全てのスキーマを定義すると、スキーマが増えてくるにつれて管理が大変になると思います。
そこで、ZModel ファイルを分割してスキーマ定義する方法を紹介します。

今回の例では ZModel ファイルを以下のように分割してみます。

- base.zmodel: generator や datasource を記述するファイル
- user.zmodel: user のスキーマ
- post.zmodel: post のスキーマ

base.zmodel

```
// importに分割したZmodelファイルをすべて記載します
import "user"
import "post"

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

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

user.zmodel

```
model User {
  id Int @id() @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt()
  email String @unique()
  name String
  posts Post[]
}
```

post.zmodel

```
model Post {
  id Int @id() @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt()
  title String
  content String?
  published Boolean @default(false)
  author User? @relation(fields: [authorId], references: [id])
  authorId Int?
}
```

変換元のファイルを「base.zmodel」に指定して変換すると、以下のような Prisma Schema が生成されます。

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

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

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

model Post {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    title String
    content String?
    published Boolean @default(false)
    author User? @relation(fields: [authorId], references: [id])
    authorId Int?
}
```

### 属性

ZModel でのみ使用できる属性を一部紹介します。
詳しい内容は[公式リファレンス](https://zenstack.dev/docs/reference/zmodel-language#attribute)をご確認ください。

#### @password

データベースにハッシュ化した文字列を登録/更新します。
内部的には[bcryptjs](https://github.com/dcodeIO/bcrypt.js#readme)ライブラリを使用してハッシュ化しているようです。

以下のように引数が定義されていて、saltLength からハッシュのコストを設定したり、salt の設定も可能です。

```
@password(saltLength: Int?, salt: String?)
```

#### @omit

この属性を指定したフィールドはデータ呼び出し時に値が取得されなくなります。
上記の@password と組み合わせて使用すると便利です。

## まとめ

最近リリースされたばかりのフレームワークだからなのか、情報量が少なく調べるのに苦労しました。
今回は ZModel を重点的に紹介しましたが、他にも魅力的な機能がたくさんあるライブラリなので、次の機会に紹介したいと思います！

## 参考

- https://ZenStack.dev/
- https://www.ey-office.com/blog_archive/2023/09/20/i-learned-a-little-more-about-zenstack-zmodel-is-useful/
- https://www.Prisma.io/docs/orm/Prisma-schema/data-model/models
- https://zenn.dev/smish0000/articles/f1a6f463417b65


logo.png

ZenStack を使用してデータベーススキーマを作成する

## はじめに

Google Cloud の [Cloud Run](https://cloud.google.com/run?hl=ja) を使ってインターネット上に公開せず内部からのアクセスのみを受け付けるサービスを構築する場合、いくつかの方法がありますが認証オプションを「認証が必要」にしてデプロイする方法がもっとも簡単です。

 ![cloud-run-deploy](https://cont.sterfield.co.jp/uploads/cloud_run_deploy_0b4c2235ac.png) 


この方法でデプロイした Cloud Run サービスの URL にブラウザでアクセスするとリクエストに認証情報が含まれてないため

```
Error: Forbidden
Your client does not have permission to get URL / from this server.
```

というエラーが表示されます。このエラーを回避して、アクセスする方法のうち代表的な3パターンを紹介します。

## 前提

Node.js で書かれたアプリケーションがデプロイされた次の 2 つの Cloud Run サービスがデプロイされている環境があるとします。

- 「Front」はインターネット上から直接アクセスされることを想定しているため、認証オプション「未認証のアクセスを許可」を設定してデプロイされている
- 「Internal」は「Front」から内部でアクセスされるもので外部からのアクセスを拒否したいため、認証オプション「認証が必要」を設定してデプロイされている

![cloud-run-diagram](https://cont.sterfield.co.jp/uploads/cloud_run_diagram_a0a3472409.png) 

## ① 他の Cloud Run サービスからアクセスする方法

「Front」 → 「Internal」

同じプロジェクトでデプロイされた Cloud Run 同士でアクセスする場合、[Google Auth Library](https://github.com/googleapis/google-auth-library-nodejs)を使うことで認証に必要なトークンを含んだ HTTP ヘッダーが取得できます。

「Front」の Cloud Run サービスをデプロイしたサービスアカウントに`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されている場合、下記のようなコードでアクセスが可能になります。

```
import { GoogleAuth } from "google-auth-library";

・・・

const auth = new GoogleAuth();
const client = await auth.getIdTokenClient(`${「Internal」のURL}`);
const headers = await client.getRequestHeaders();

// headersの中に Authorization: Bearer ${トークン} が設定されている
await fetch(`${「Internal」のURL}`, { headers });
```

## ②Cloud Run 以外のサービスからアクセスする方法

Cloud Scheduler → 「Internal」

[Cloud Scheduler](https://cloud.google.com/scheduler?hl=ja)から「Internal」にアクセスする場合は、HTTP ターゲットを作成する際、Auth ヘッダーを「OIDC トークンを追加」に設定してサービスアカウントに`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されているものを設定すると、自動でトークンを付与した HTTP アクセスを行ってくれます。

 ![cloud-scheduler](https://cont.sterfield.co.jp/uploads/cloud_scheduler_74457eda15.png) 

[Cloud Pub/Sub](https://cloud.google.com/pubsub?hl=ja)などでも同じように OIDC 認証を設定することでアクセス可能になります。

## ③ ローカルからアクセスする方法

開発者のローカル PC のコンソール → 「Internal」

gcloud CLI を使うことで開発用の汎用 ID トークンを生成することができます。`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されているユーザーでログインして、[`gcloud auth print-identity-token`](https://cloud.google.com/sdk/gcloud/reference/auth/print-identity-token)を実行するとログインユーザーのトークンが取得できます。

curl コマンドと組み合わせて下記の様に実行することでアクセスが成功します。

```
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" ${「Internal」のURL}
```

## まとめ

今回紹介した内容はすべて Google Cloud の公式ドキュメントに記載されているものですが、複数のページにまたがって解説されており、個人的に探すのが大変だったのでブログにまとめました。同じような苦労をされている方のお役に立てれば幸いです。

## 参考リンク

- https://cloud.google.com/run/docs/tutorials/secure-services?hl=ja
- https://zenn.dev/steelydylan/scraps/60f3536dd0c9b4
- https://cloud.google.com/scheduler/docs/http-target-auth?hl=ja
- https://cloud.google.com/run/docs/authenticating/developers?hl=ja#curl

cloud_run.png

認証が必要な Cloud Run サービスにアクセスする方法まとめ

## はじめに
フロントエンドにおいても、製品の品質を向上させ、維持していく上で、テストは必須と言えるほど重要になってきています(参考: <a href="https://roadmap.sh/frontend" target="_blank" rel="noopener noreferrer">Frontend Developer Roadmap</a>)。  
テストの状態を計測するよく使われる指標の一つとして、テストのカバレッジ率があります。  
フロントエンドのテストは、主に単体テスト、統合テスト（コンポーネントテスト）、E2Eテストに分けられます。  
Cypressでは基本的にこれらすべてを一元的に実装できるため、テストを書く上で便利です。  
ただ、CypressはJestやJestベースのPlarywrightと違って、標準ではカバレッジレポートを出力できません。  
特にNext.jsでは<a href="https://docs.cypress.io/guides/tooling/code-coverage" target="_blank" rel="noopener noreferrer">公式で紹介されている方法</a>そのままでは計測できなかったので、  
Next.jsとCypressを使ったサイトでテストカバレッジ率を計測する方法について、  
実際に検証しながら整理してみました。

※この記事では、Cypressの導入部分は省略します

## 全体の流れ
1. 計測のためのプラグインを追加する
1. package.json レポートのオプションを追加
1. Cypress の config に計測のための設定をを追加
1. Cypress の 共通設定部分にプラグインの読み込みを追加
1. Next.js の config にプラグインの記述を追加
2. テストを実行し、レポートを表示する

## 計測のためのプラグインを追加する
Cypressでカバレッジ率のタスクを実行するための **@cypress/code-coverage** と Next.jsでレポートを作成するための **swc-plugin-coverage-instrument** をインストールします。
```bash
npm i -D @cypress/code-coverage swc-plugin-coverage-instrument
```

## package.json レポートのオプションを追加
レポートに含めたいファイルや、含めたくないファイルがある場合、以下のように"nyc"の項目を追加して、オプションを指定します。

###### package.json
```diff
{
  "name": "example",
  ︙
  },
+  "nyc": {
+    "extension": [".ts", ".tsx"],
+    "include": ["pages/**/*.tsx", "src/**/*.ts", "src/**/*.tsx"],
+    "exclude": ["node_modules/**", "mock-data/**", "cypress/**", "**/*.cy.ts"],
+    "excludeNodeModules": true,
+    "excludeAfterRemap": true
+  }
}
```

## Cypress の config に計測のための設定を追加
cypress.config.ts へ以下のように、コードカバレッジを計測するための設定を追加します。

###### cypress.config.ts
```diff
import { defineConfig } from "cypress";
+ import codeCoverageTask from "@cypress/code-coverage/task";

export default defineConfig({
  env: {
    enableMock: true,
+    codeCoverageTasksRegistered: true
  },
  e2e: {
+    setupNodeEvents(on, config) {
+      codeCoverageTask(on, config);
+      return config;
+    },
    baseUrl: "http://localhost:3000"
  },
  component: {
    devServer: {
      framework: "next",
      bundler: "webpack"
    },
    defaultCommandTimeout: 6000,
+    setupNodeEvents(on, config) {
+      codeCoverageTask(on, config);
+      return config;
+    }
  }
});
```

## Cypress の 共通設定部分にプラグインの読み込みを追加
cypress/support/component.ts や cypress/support/e2e.ts に、  
プラグイン読み込みのコードを追加します。
###### cypress/support/component.ts | cypress/support/e2e.ts
```diff
+ import "@cypress/code-coverage/support";
```

## Next.js の config にプラグインの記述を追加
next.config.js のビルド設定部分にも、プラグインの記述を追加します。

###### next.config.js
```diff
const withImages = require("next-images");

module.exports = withImages({
  trailingSlash: true,
+  experimental: {
+    swcPlugins: [
+      ["swc-plugin-coverage-instrument", {
+        compact: false
+      }]
+    ],
+  },
});
```

## テストを実行して、レポートを表示する
これで、準備ができましたので、実際にテストを実行してレポートを表示してみます。

### テストを実行
テストの script は package.json で以下のように設定しているとします。
```diff
{
  ︙
  "scripts": {
    ︙
+    "cypress": "cypress open",
+    "cypress:e2e": "cypress run --e2e",
+    "cypress:component": "cypress run --component"
    ︙
  },
  ︙
}
```

コンポーネントテストを実行してみます。
```
npm run cypress:component
```
テストが終了すると、以下のディレクトリにファイルが生成されます。  
- coverage
- .nyc_output

coverage/lcov-report/index.html を表示すると、  
以下のようなレポートを確認できます。  
  
 ![](https://cont.sterfield.co.jp/uploads/report_gui_883931f06d.png) 

また、以下のようにコマンドを打つことで、概要を表示できます。
```bash
npx nyc report --reporter=text-summary 
```
  
 ![](https://cont.sterfield.co.jp/uploads/report_cl_7970bcc25b.png) 
状態、分岐、関数、行数など、色々な方向で評価してくれます。

## まとめ
Next.jsでは、バンドラーがSWCなため、公式ドキュメントに従って設定すると実行が難しいことがわかりました。  
ただ、調査を進めることで、レポートの取得が可能であることがわかりました。  
今後はこれを活用し、Next.jsとCypressを組み合わせて効果的なテスト運用を構築していく予定です。  
この組み合わせにおいては、準備が整えば手軽にテストレポートを取得でき、より効率的かつ信頼性の高い開発プロセスを構築できると考えています。  
今回の課題を克服することで、将来的なプロジェクトでの利用をスムーズに進めることが期待できます。  
Next.js ✖️ Cypressの組み合わせを最大限に活かし、テストの品質向上に貢献していきます。

## 参考リンク

- [Frontend Developer Roadmap](https://roadmap.sh/frontend)
- [Code Coverage | Cypress Documentation](https://docs.cypress.io/guides/tooling/code-coverage)
- [swc-plugin-coverage-instrument](https://github.com/kwonoj/swc-plugin-coverage-instrument?tab=readme-ov-file)

nino-eye.jpg

Next.jsとCypressを使ったWebアプリでテストのカバレッジ率を計測する

2024年1月にアメリカのウォルトディズニー社の初期作品「蒸気船ウィリー」の著作権が消滅しパブリックドメインとなりました。この作品はミッキーマウスが初めて登場したアニメーションであり、著作権が無くなったことで、この作品のストーリーや登場したミッキーマウスをはじめとするキャラクターを自由に使って創作できるようになります。  
このニュースがあり、早くも「蒸気船ウィリー」を題材にしたホラー映画やゲームが発表されるなどの動きがありました。
  
スターフィールドは映像制作をする会社ではありませんが、デザインやシステムなどのものづくり行っています。そのため、無関係のニュースとは言い難いです。  
制作業務を行う者として、漠然と他者が作ったものは無断では使えないという認識を当然のように持っていますが、そもそも著作権とは何なのか、調べてみました。  
  
## 著作権に法的な有効利用がある理由
  
先ず前提として社会は、誰かが作った知的財産は制作者が永続に独占するより、人類共有の財産として誰もが自由に使える方が良いと考えています。その方が産業や文化を育むことに貢献できます。  
  
現にディズニーの作品も「シンデレラ」「不思議の国のアリス」「白雪姫」など、おとぎ話を題材にした作品があります。ディズニーがこれらの作品を題材にしアニメーション映画を作り、それにより文化の発展に貢献したことは間違いありません。  
  
しかし、その一方で誰もが自由に作品を使用できるなら、制作者の利益を守ることができません。著作権は制作者が作品を通じて収益を得る能力と、公共の文化の発展に寄与にすることのバランスを取るために存在しています。  
  
## 著作権の国際ルール  
  
著作権に国境はありません。著作物は国境を越えて利用されるので19世紀末から国際条約を結んで保護してきました。しかし、何を保護するのか？また、作品の権利はいつの時点で派生するのか？など法で銘文化してその対象を定めるのは考え方も色々あり、一筋縄ではいきません。  
  
例えば、日本をはじめとするベルヌ条約を結んだ国家間では作品を作った後、無方式主義をとっており、特に登録などの手続きをしなくても制作物の著作権を得られます。一方、アメリカや中南米では方式主義を取っており、作品を作った後に著作権庁に登録することで著作権が認められます。  
  
このように考え方も異なり、また社会の発展により新しいメディアが登場すると新しく保護するべき物が増えてきます。そのため社会情勢や技術の進歩により保護対象を広げたり、新たな協定や条約を作ってきたようです。  
  
なお、現在では、アメリカのように方式主義をとっている国でも「"&copy;"（コピーライツマーク）」を掲示することで保護の対象になるよう条約のルールで決められています。
  
 ![](https://cont.sterfield.co.jp/uploads/c_mark2_6f537d4ee1.png) 

  
簡単に主な国際条約をまとめてみました。
  
|              | ベルヌ条約 | 万国著作権条約 | 
| ------------ | --------- | -------------- | 
| 創設年       | 1886年     | 1952年         | 
| 日本の締結年 | 1899年     | 1956年          | 
| 加入国数     | 179        | 180            | 
| 主な目的     | 学的及び美術的著作物の保護 | 文学的及び美術的著作物の保護&#124;欧州を中心としたベルヌ条約と米国、中南米を中心としたパンアメリカン条約の精度の調整 | 
| 特長         | 無方式主義（作品を作った後、登録などの手続きは不要）　など | 無方式主義国の著作物であっても©表示によって保護　など |
  
  
|              | ローマ条約 | レコード条約 | 
| ------------ | --------- | -------------- | 
| 創設年       | 1961年     | 1971年         | 
| 日本の締結年 | 1989年     | 1978年           | 
| 加入国数     | 96        | 80            | 
| 主な目的     | レコード製作者、実演家、放送機関などの保護 | レコード製作者の保護 | 
| 特長         | 放送という場面で、実演家や商業用レコードの二次利用について規定　など | 許可されてないレコードの複製、輸入、配布を禁止　など |
  
  
|              | TRIPS協定 | WIPO著作権条約（WCT） | 
| ------------ | --------- | -------------- | 
| 創設年       | 1994年     | 1996年         |
| 日本の締結年 | 1994年     | 2000年          |
| 加入国数 | 164 | 113 |
| 主な目的 | 貿易の際、知的所有権に関する協定 | 著作権に関する世界知的所有権機関条約 |
| 特長 | プログラム、データベース、映画、レコードの著作権と貸与に関する権利の保護　など | 著作物の譲渡権、貸与権、利用可能化権について規定　など |
  
  
|              | 北京条約 | マケラッシュ条約 | 
| ------------ | --------- | -------------- | 
| 創設年 | 2012年 | 2013年 |
| 日本の締結年 | 2020年 | 2018年 |
| 加入国数 | 47 | 92 |
| 主な目的 | 視聴覚的実演に関する条約 | 視覚や聴覚の障害がある人が著作物を利用する機会を促進 |
| 特長 | 実演家氏名の表示や同一性を保持する権利の規定　など | 障害に合わせて著作物を改変する際の制限についての規約　など |
  
  
など、多岐にわたる条約があります。
どのルールが適用されるのか？これは専門家の間でも意見が分かれてしまいますが、
共通することは  
  
・著作物を守る意識が働いていること  
・自国の著作物と同様に外国の著作物も守ること  
  
という点です。
  
しかし、話が複雑になる点ですが、保護期間はその国よって異なります。
  
## アメリカと日本の違い
  
著作物は加盟国で守ることは決まっていますが、自国の著作物と同様に権利を与えるというのが基本方針です。  
そのため、保護期間はその国の考え方で異なります。  
  
今回話題にした「蒸気船ウィリー」を例にするとアメリカは発表年（登録年）からカウントします。期間については紆余曲折があったようですが最終的に95年間になりました。そのためアメリカでは2024年からパブリックドメインになり、初期のミッキーマウスも自由に使えます。  
  
しかし、日本の場合は、このような単純な話ではありません。作品が団体名義か、個人名義かでも期間が変わります。というのはアメリカと違い、団体名義なら発表年からカウントし、個人名義なら作者が生存している期間と死後も保護期間があるからです。  
また、ミッキーマウス単体で考えた場合、ミッキーマウスの原画という絵があります。という事は映画の付属物なのか、美術品なのか？という見解でまた保護期間が異なります。
  
更に日本は連合国と戦争していた歴史があり、平和条約を結ぶ際に、戦争中の期間である10年5ヶ月分も別途保護期間として加算することが決められています。  
  
つまり、日本においてのミッキーマウスの著作権は以下のルールが当てはまることになります。

### ミッキーマウスの保護に影響するルール
  
1. 1928年11月時点（蒸気船ウィリーの発表年）の著作権の保護期間は団体名義なら発表から33年、個人名義なら死後38年間に定められていた。
2. 1970年新たな著作権法が施行され、映画や団体名義の保護期間は発表から50年、美術品は作者の死後50年に延長。また、この法律が施行された時点で保護対象となっている作品も同じく50年間に延長。
3. 2004年、映画の保護期間を公表から70年に延長し、保護対象の作品も延長の対象となった。
4. ルール3に基づく保護期間と、ルール1に基づく保護期間を比べた場合、長い方の保護期間が採用される。
5. 2018年映画以外の著作権の保護期間を20年間延長が決定。
6. 平和条約の義務により、戦争中の期間も保護対象となるため、戦前の連合国の作品は保護期間が別途10年5ヶ月加算される。
  
  
このため、6通りの見解が出てしまい、結論はまだ出ていません。以下にそれぞれ解説します。  
  
### 見解1　ミッキーマウスは映画の一部であり、ディズニー社の著作物である。  
  
保護期間：1989年5月まで
  
この見解に基づいた場合、当時の映画の保護期間は33年なので1961年まで、更にルール6が加算され1972年5月まで延長されます。70年の時点で保護対象である作品という事はルール3も適用され保護期間は50年に延長されます。従って、1989年5月で終了　となります。  
  
しかし、かつてチャップリンの映画の保護期間で、映画監督チャップリンの制作物なのか？映画製作会社の作品なのか？の見解で、裁判になりました。結果、最高裁がチャップリン個人の作品と判断しましたので、映画は監督の死後から保護期間を数えるのが通例となります。よって、この見解は通じないと思われます。
  
  
### 見解2  ミッキーマウスは映画の一部であり、ウォルト・ディズニー氏の作品である。  
  
保護期間：2015年5月まで
  
この場合、ウォルト・ディズニー氏が亡くなったのは1966年12月なので、ルール1に基づき死後38年間までが保護対象なので2004年ま、そこにルール6が加算され、2015年まで5月までとなります。  
  
2004年時点で保護期間があるという事はルール3の発表年から70年というルールも適用範囲ですが、この考えとルール6が加算されると2009年5月までとなります。しかし、このような場合はルール4に該当し、期間が長い方である　2015年5月までが期間となります。  
  
  
### 見解3  ミッキーマウスは映画の一部であり、アブ・アイワークス氏の作品である。
  
保護期間：2020年5月まで
  
アブ・アイワークスはウォルト・ディズニーと共にスタジオを立ち上げた人物です。またミッキーマウスの造形の殆どは彼が担当して制作したようです。当然映画製作に大きくかかわり、蒸気船ウィリーのクレジットには「アブ・アイワークス作　ウォルト・ディズニーアニメ」と表記されています。また、アブ・アイワークスはウォルト・ディズニーより長生きし、1971年に亡くなりました。　　
ということはこの時点から算出し、2020年5月までとなります。
  
  
### 見解4　ミッキーマウスは美術作品でもあり、ウォルトディズニー社の制作物である。
  
保護期間：1989年5月まで
  
見解1～3はミッキーマウスが映画の一部という前提の場合の保護期間です。しかし、ミッキーマウスというキャラクターは原画があり、キャラクターその物が独立して著作権があるという考え方もできます。  
  
そして、キャラクターの制作者がウォルト・ディズニー社という団体であると見ることもできます。この場合、考え方は概ね見解1と同様です。しかし、同じく同様の理由で認められないでしょう。
  
  
### 見解5　ミッキーマウスはウォルト・ディズニー氏名義の美術作品である。  
  
保護期間：2047年5月まで
  
個人名義であるならルール1により死亡した段階で、1966年から算出され2004年までであり、1970年時点で保護対象となるのでルール2が適用され2016年まで延長されます。さらにルール6の戦争中の期間も加算されて2027年5月まで延長します。  
2018年時点で保護対象となるなら、ルール5も適用され保護期間は死後70年という扱いになり、2047年5月まで、という判断になります。
  
  
### 見解6　ミッキーマウスはアブ・アイワークス氏名義の美術作品である。  
  
保護期間：2052年5月まで
  
上述したようにミッキーマウスの誕生にはアブ・アイワークス氏の功績が大きく、ミッキーマウスはこの方の作品という見方もできます。という事はアブ・アイワークスの死亡年から算出するので2052年5月までという判断になります。
  
  
  
こうしてみると日本国内では「蒸気船ウィリー」の著作権は切れているが「ミッキーマウス」の著作権は切れていないという事になります。つまり現時点で断言できることは、  
  
蒸気船ウィリーを題材にした作品を作ることができるが、ミッキーマウスなどのキャラクターは使わずオリジナルのキャラクターを使わなくてはいけない
  
という事になります。
  
  
## まとめ  
  
今回著作権について調べてみましたが、その内容は複雑で全てを把握できませんでした。特に国家間をまたぐ場合はその国の考え方次第でルールも全然違うようです。そのためよく調べ、必要なら専門家の意見を聞くようにしないと思わぬトラブルになるでしょう。  
今回も「ミッキーマウスの著作権が切れた」というニュースで安易に使用していたら権利を侵害したかもしれません。  
  
いずれにしろ、権利を守る意識は国際的にも浸透しているので制作者としてはルールを尊重し業務を行うべきと思いました。
  
  
#### 参考記事
  
・骨董通り法律事務所  
https://www.kottolaw.com/column/190913.html  
  
・公益社団法人著作権情報センター  
https://www.cric.or.jp/qa/hajime/hajime5.html  

mv.png

ミッキーマウスの著作権が切れたというニュースから「著作権」について調べてみました

## はじめに

2023 年 10 月に[Gmail のメール送信者ガイドライン](https://support.google.com/mail/answer/81126)がアップデートされました。<br>
2024 年 2 月から適用されるので、ギリギリになってしまいましたが、ガイドラインからどのような設定が必要なのかをまとめました。

## 対象となる送信者

個人用 Gmail アカウントに 1 日あたり 5,000 件以上のメールを送信している場合が対象になります。<br>
個人用 Gmail アカウントとは、末尾が @gmail.com または @googlemail.com のアカウントを指します。<br>
現在のガイドラインでは Google Workspace を利用しているアカウントは対象外ですが、今後のアップデートで Google Workspace を利用しているアカウントも対象になる可能性があるので、個人用 Gmail アカウントにメールを送信していなくても今のうちに設定しておくことをおすすめします。

### 5,000 件のカウント方法について

同じプライマリドメインから送信されたすべてのメールが対象になります。<br>
例えば、1 日あたり@example.com から 3,000 件、@sub.example.com から 2,500 件送信している場合、5,500 件とカウントされます。

## ガイドラインの適応スケジュール

[Google の FAQ](https://support.google.com/a/answer/14229414)によると、以下のスケジュールで順次対応するようです。

### 2024 年 2 月

要件を満たしていないメールのうち、一部のメールが一時的なエラーを受け取るようになります。

### 2024 年 4 月

要件を満たしていないメールの拒否を開始します。<br>
一部のメールから拒否をし始めて、徐々にその割合を増加します。

### 2024 年 6 月

全ての商用メール、プロモーションメールに、ワンクリックでの登録解除を実装する必要があります。

## 対応が必要な内容

今回のガイドラインで対応が必要な項目は下記の通りです。

- 送信ドメインで SPF と DKIM を設定する
- 送信元のドメイン、 IP アドレスに正引き、逆引き DNS レコードを設定する
- メールの送信に TLS 接続を使用する
- [Postmaster Tools](https://gmail.com/postmaster/)で報告される迷惑メール率を 0.1%未満に維持する
- [RFC 5322](https://datatracker.ietf.org/doc/html/rfc5322)に準拠する形式でメールを作成する
- DMARC を設定する
- メーリングリスト等、転送する場合は ARC ヘッダを追加する
- ヘッダ From ドメインは SPF、DKIM ドメインと一致させる
- ワンクリックでの配信停止に対応する

## DNS レコードについて

DNS（Domain Name System）とは、インターネット上でドメイン名と IP アドレスを紐づけるためのシステムです。<br>
今回のガイドラインでは、送信元ドメインの A レコードから送信元 IP アドレスを参照できるようにし（正引き）、逆に送信元 IP アドレスの PTR レコードから送信元ドメインを参照できるようにする（逆引き）必要があります。

### DNS レコードの例

「example.com」から IP アドレス「172.16.0.1」を参照（正引き）する設定は以下のように記述します。

```
example.com. IN A 172.16.0.1
```

IP アドレス「172.16.0.1」から「example.com」を参照（逆引き）する設定は以下のように記述します。

```
1.0.16.172.in-addr.arpa. IN PTR example.com
```

「1.0.16.172.in-addr.arpa.」の部分は、以下の手順で変換したものを記載します。

1. IP アドレスの各オクテットを逆順に並べる
   「172.16.0.1」の場合は「1.0.16.172」のようにします
2. IP アドレスが IPv4 形式の場合は、後ろに「.in-addr.arpa.」を記述する
   ※ IPv6 形式の場合は「.ip6.arpa.」を付与します

## SPF レコードについて

SPF（Sender Policy Framework）とは、電子メールの送信元ドメインが詐称されていないかを検査するための仕組みです。<br>
メールを受信する際に受信側は送信側の DNS ヘ SPF レコードを要求し、返答された SPF レコードが受信したメールの実際の送信元 IP アドレスと一致するかを確認します。<br>
2 つの IP アドレスが一致すれば認証が成功し、ドメインの管理者が意図した通りのメールサーバーから届けられた正しい送信元からのメールであることが証明できます。

### SPF レコードの例

「example.com」の IP アドレス「172.16.0.1」から送信されたメールアドレスのみを認証する場合は、以下のように記述します。

```
example.com. IN TXT "v=spf1 ip4:172.16.0.1 -all"
```

## DKIM レコードについて

DKIM（DomainKeys Identified Mail）とは、電子メールの送信元ドメインの認証技術の一種です。<br>
メール送信者が秘密鍵を使ってメールに署名し、受信者は送信元ドメインの公開鍵を使って、この署名の正当性を検証します。<br>
署名が正当であれば、そのメールは送信元ドメインの管理者が意図した通りのメールサーバーから届けられた正しい送信元からのメールであることが証明できます。

### DKIM レコードの例

DKIM レコードは下記のように記載します。<br>
セレクタ名は、任意の最大 63 文字の英数字を設定できます。<br>
ただし、セレクタ名はドメインに対して一意である必要があります。

```
[セレクタ名]._domainkey.example.com. IN TXT "v=DKIM1;k=rsa;p=[公開鍵]";
```

## DMARC レコードについて

DMARC（Domain-based Message Authentication, Reporting and Conformance）とは、電子メールの送信元ドメインの認証技術の一種であり、SPF や DKIM と併用することで、なりすましメール対策の強化が期待できます。<br>
DMARC の仕組みは、以下の 3 つに分けられます。

- 認証
  DMARC は、SPF と DKIM の認証結果を組み合わせて、メールの送信元ドメインの正当性を検証します
- ポリシー
  DMARC は、認証に失敗したメールをどのように処理するかを、ポリシーとして定義できます
- レポート
  DMARC は、認証結果を送信元ドメインに報告できます

ポリシーは、以下の 3 種類に分けられます。

- p=none
  認証に失敗したメールをすべて受信する
- p=quarantine
  認証に失敗したメールを、受信者から隔離する
- p=reject
  認証に失敗したメールを、受信者に拒否する

### DMARC レコードの例

「example.com」でポリシーを「none」、レポートの送り先を「dmarc-fb@example.com」に設定する場合、以下のように記述します。

今回のガイドラインでは、ポリシーは「none」でも問題ありません。

```
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-fb@example.com"
```

## ARC ヘッダについて

ARC（Authenticated Received Chain）とは、メールの認証状況を伝達し、なりすましメールや不正な改ざんを防ぐための技術です。<br>
SPF、DKIM、DMARC と連携して、メールの信頼性をさらに高める役割を果たします。<br>
メーリングリストやメールボックスプロバイダの自動転送機能などでメールを転送する場合、SPF や DKIM が失敗することがあるため、それを回避するために ARC ヘッダを追加する必要があります。

## TLS 接続について

TLS（Transport Layer Security）とは、インターネット上での通信を暗号化し、安全性を高めるための技術です。HTTPS や IMAP、POP3、SMTP などのプロトコルで使用され、通信内容の盗聴や改ざん、なりすましを防ぎます。

TLS 接続に対応しているメール配信システムを利用していれば問題ありません。

## ワンクリックでの配信停止について

今回のガイドラインでは、マーケティング目的のメールは 1 クリックでの配信停止の対応が必要です。<br>
具体的には、[RFC8058](https://datatracker.ietf.org/doc/html/rfc8058)に従い、以下をメールヘッダに含む必要があります。

配信停止リクエストを API 等で処理する場合は下記のように記述します。

```
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe>
```

配信停止リクエストを指定されたアドレスにメール形式で送信する場合は下記のように記述します。

```
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <mailto:unsubscribe@example.com>
```

[Google の FAQ](https://support.google.com/a/answer/14229414)によると、メール本文内の配信停止リンクを設置するだけでは要件を満たさないのでご注意ください。

## 各種設定の確認方法

設定が正しく適用されているか確認するためのツールを紹介します。

### [dmarcian](https://dmarcian.com/)

SPF、DKIM、DMARC レコードを診断してくれるツールです。

### [mail-tester](https://www.mail-tester.com/)

メールを実際に分析し、送信ドメイン認証のほか、様々な観点で送信メールのチェックを行い、10 点満点で評価をしてくれます。

## まとめ

ガイドラインの要件を満たしていない場合、メールがブロックされたり、迷惑メールに振り分けられたりする可能性が高くなるので、なるべく早く対応することをおすすめします。<br>
また、[ガイドライン](https://support.google.com/a/answer/81126)は今後も更新される可能性があるため、定期的にチェックしましょう。<br>
また、Google だけでなく、[米国 yahoo でも同様のアナウンス](https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam)がされていますので、利用している方はこちらも対応が必要です。

## 参考

- https://blastmail.jp/blog/spam/gmail-guideline-202402
- https://sendgrid.kke.co.jp/blog/?p=17213
- https://sendgrid.kke.co.jp/blog/?p=5190
- https://sendgrid.kke.co.jp/blog/?p=1822
- https://www.value-domain.com/media/spf-record/
- https://www.cloudflare.com/ja-jp/learning/dns/dns-records/dns-dkim-record/
- https://hp-shizuoka.jp/column/2016/10/7515/
- https://baremail.jp/blog/2022/06/16/2552/
- https://docs.oracle.com/ja-jp/iaas/Content/Email/Tasks/configure-dkim-using-the-console.htm


20240202_1.jpg

Gmail 送信のガイドラインへの適応

# Webページの画像と原稿制作について

このページとはパソコンとスマートフォンで見比べてご覧ください。  
  
 ![](https://cont.sterfield.co.jp/uploads/qr_reference_materials_72c097b82b.png) 

スターフィールドでは、ECショップのシステムを提供しています。ご利用いただいているお客様から、画像や原稿の作成方法についてよくお問い合わせをいただきます。
お問い合わせ内容を見ると、スターフィールドのシステムに限定したものだけでなく、Webサイトに掲載する素材全般に共通するポイントが多いようです。  
  
そこで、普段Web制作をされていない方がWebサイト用の画像や原稿を作成される際に、気を付けたいポイントについてご紹介します。
  
## 画像サイズの説明
  
Webサイトで画像を作る際には、画面幅とコンテンツ幅の横幅を意識し、どのように掲載されるのかを考えていきます。
  
画面幅は文字通り、画面全体の表示領域です。  
現在ご覧になっているこの記事ページで言うのであれば、画面左上のスターフィールドのロゴから画面右上のメニューアイコンまでの幅を指します。
  
一方、コンテンツ幅はそのページの記事が表示されている領域です。  
このページで言うなら、この記事のテキストが掲載されているエリアとその横側についているボタン類迄です。スマートフォン版で見た場合はこのボタン類はテキストの下に配置されています。  
一般的に、パソコンのWebページでは、画面幅は1500px以上、コンテンツ幅は最大1,000px～1,200px程度で作成されます。このページのコンテンツ幅は最大1,100pxです。  

そのため、パソコンの画面の端から端まで大きく表示される画像は、1500px～2000px程度の大きさで作成されることが多く、コンテンツ幅内に表示される画像は640px以上で作成されることが多くなります。  
  
スターフィールドの業務に関しては、ECショップに関わることが多いです。  
ECショップでは、商品画像やその解説に関わる画像が最も多く使用されます。また、商品は一般的に、図1のように一覧ページと詳細ページに分けて表示され、一覧で商品をクリックすると詳細ページに移動されることが一般的です。
  
図1  
 ![](https://cont.sterfield.co.jp/uploads/sample_pc_fc38f80361.png) 

  
このように画面をレイアウトする場合、写真のサイズは、実際には640pxよりも小さくなります。
具体的には、一覧画面では200px～300px程度、詳細画面でも500px程度が一般的です。  
  
近年のWebサイトは、パソコンだけでなくスマートフォンでも閲覧されることを想定して作られるケースが増えています。そのため、パソコンでもスマートフォンでも快適に閲覧できるよう、画像のサイズを調整して作成することが多いのです。スターフィールドのシステムでも同様です。
  
では、ECショップを例にした場合、スマートフォンでは図2のようなレイアウトが多いと思います。
  
図2  
 ![](https://cont.sterfield.co.jp/uploads/sample_sp_9aebe8495f.png) 
  
パソコンと比べると、スマートフォンの画面は小さくなっています。また、多くのWebサイトでは、画面幅とコンテンツ幅が同じになっており、詳細ページでは、画面の端から端まで商品画像が表示されることが多くあります。そのため、スマートフォンの画面の端から端まで表示しても問題ないサイズの画像を用意する必要があるのです。

スマートフォンの画面サイズは機種によって異なりますが、端から端まで表示する場合は、640pxに設定されていることが多いようです。また、デジタル画像は拡大すると画質が落ちるものの、縮小すると画質が劣化しにくい性質があります。この性質を利用して、画像は640pxで作成し、必要に応じて縮小して表示する仕組みでWebサイトを作成することが多いです。

そのため、お客様から制作者側に提供する画像は、トップページなどの大きな画像を除き、コンテンツ内に表示させるものであれば、640px以上のサイズのものを提供いただくことで作成や更新がスムーズに進みます。

## 文字つきの画像データを作成する際の注意
  
画像の中に文字を入れる場合、画像のサイズが画面幅に応じて変化するため、文字のサイズも変化することに注意が必要です。
実際に図3をご覧ください。

  
図3  
 ![](https://cont.sterfield.co.jp/uploads/sample_1500_8193643d79.png) 

  
図3は、パソコンの画面幅に合わせて横幅1500pxで作成されています。このサイズは、パソコンの画面を端から端まで表示させることを想定しています。
  
しかし、このブログのテキストの表示領域は最大825pxなので、パソコンで見た場合は55%に縮小されて表示されてしまいます。スマートフォンで見た場合はさらに縮小されます。


このように、画像のサイズが画面幅に応じて変化すると、画像内に記載された文字も一緒に縮小されてしまいます。そのため、文字の視認性が著しく低下してしまいます。図3の画像内で一番小さい文字は、14ptで作成されていますが、縮小されたことで読みにくくなっていることが確認できます。
  
Webページのテキストは、一般的に14px～16pxのサイズで作成されます。ptとpxは異なる単位ですが、14ptは約18px相当になります。そのため、文字を読みやすくするためには、14pt以上の大きさで作成することを意識しましょう。
  
また、パソコンの画面幅に合わせて画像を作成すると、スマートフォンではさらに文字の視認性が悪くなります。そのため、このような大きな画像については、図4のようにスマートフォン版専用の画像を用意して、パソコンとスマートフォンで異なる画像を表示するように設定します。

図4    
 ![](https://cont.sterfield.co.jp/uploads/sapmle_640_b27b695332.png) 

  
ネットショップの場合、商品画像に「新発売」などの数文字のフレーズを入れる分には、さほど問題になるケースは少ないでしょう。しかし、商品の説明について、成分の解説や商品ができるまでの過程をグラフィカルにまとめた資料をお客様が作成する場合は、注意が必要です。
  
画面幅に応じて画像のサイズも変化し、記載されている文字も合わせてサイズが変化することを想定せずに画像を作成すると、パソコンやスマートフォンで文字が読みにくくなる傾向にあります。また、デザインによっては、パソコン版とスマートフォン版で別々の画像を作成する必要があり、手間が増えることもあります。
  
## テキストについて
  
お客様から寄せられるお問い合わせの中には、テキストに関するご質問や修正依頼もあります。
  
Webページのテキストサイズは、一般的に14px～16pxを基準に設定します。デザインを行う際は、このサイズでテキストを作成して、テキスト量と画像バランスを考慮してデザインします。 
  
しかし、画像サイズは閲覧する端末によって変化するため、Webページとして実際に表示した際に、想定したバランスが崩れてしまいやすいです。特に、普段、紙媒体のデザインを手がける方々からは、この点に関する指摘が多く寄せられます。
  
よく依頼される指摘の一例として、文字の改行に関するものがあります。しかし、テキストは画像とは異なり、制作者が完璧にコントロールすることが難しいため、意図しない改行が発生することがあります。
  
ディスプレイ性能やOS、ブラウザ、閲覧者の端末の設定などによって、文字サイズや文字間、行間などに微小な差異が生じます。これらの要因が重なり、制作者が意図しない改行に繋がります。
  
そのため、例えば、制作者の開発環境で最適に見えるように調整しても、別の環境で閲覧したら意図しない改行が生ずることがあります。
  
このように、Webページのテキストは、制作者の意図した通りに表示されない可能性があることを前提として、テキストと画像の配分はある程度ずれること、細かな改行指定はしない、などのことを想定して原稿を作る必要があります。
  
## まとめ
Webページは、実際に作ってみないと分からないことがたくさんあります。そのため、制作者も依頼者も、想定外のことが起こることがあります。

そのようなことが起こった場合は、ぜひご相談ください。ご要望をお聞きし、最適な解決策をご提案します。

25286080_s.jpg

Webページの画像と原稿制作について

## はじめに
先日、基本情報技術者試験の受験をしてきましたので、後に続く人に有益な情報を残すため、<br>
本記事では、基本情報技術者試験の攻略方法についてをまとめたいと思います。

## 基本情報技術者試験の実施概要
基本情報技術者試験には、午前中に実施する「科目A 試験」と、午後に実施する「科目B 試験」があります。制限時間や問題数などについては、以下のようになります。<br>
 ![](https://cont.sterfield.co.jp/uploads/2024_01_05_13_10_54_6d03b4b0e6.png) 
試験は、CBT方式で行います。(テストセンターでPCパチパチするやつです)<br>
### 科目A 試験の概要
「科目A 試験」は出題数が全部で60問あり、四肢択一式です。<br>
情報処理分野（テクノロジ系）、マネジメント分野（マネジメント系）、経営・会計分野（ストラテジ系）から出題されます。<br>
プログラミングに関する部分だけではなく、マネジメントや経営など、幅広く勉強しなくてはなりません。<br>
 ![](https://cont.sterfield.co.jp/uploads/2024_01_05_13_12_45_1b7095f228.png) 
### 科目B 試験の概要
「科目B 試験」は、多肢選択の長文読解式で20問出題されます。出題分野は、「アルゴリズムとプログラミング」と「情報セキュリティ」となり、以下のカテゴリで構成されています。<br>
- プログラミング全般（既存プログラムの解読及び変更やプログラムのテストなど）
- プログラムの処理の基本要素（型や変数など）
- データ構造及びアルゴリズム（グラフや整列など）
- プログラミングの諸分野への適用（数理やデータサイエンスなど）
- 情報セキュリティの確保（脆弱性管理バックアップなど）

## 試験の内容
*の数で重要度が表現されています。
### 1.コンピュータ構成要素
- [情報の表現](https://tamotech.blog/2022/10/16/amount-of-information/)**<br>
- [コンピュータの構成](https://tamotech.blog/2022/10/16/computer/)<br>
- [CPU](https://tamotech.blog/2022/10/22/cpu/)<br>
- [CPUの動作原理](https://tamotech.blog/2022/11/12/addressing-method/)<br>
- [CPUの高速化技術](https://tamotech.blog/2022/11/12/cpu-pipline/)<br>
- [半導体メモリ](https://tamotech.blog/2022/11/17/rom-ram/)*<br>
- [補助記憶装置](https://tamotech.blog/2022/11/26/auxiliary-storage/)<br>
- 入出力装置<br>
- [入出力インターフェース](https://tamotech.blog/2022/11/27/input-output-interface/)<br>

### 2.ソフトウェアとマルチメディア
- ソフトウェア*<br>
- [ジョブ管理とタスク管理](https://www.youtube.com/watch?v=CPCZ8hgtPl0)*<br>
- 記憶管理*<br>
- ファイル管理*<br>
- [マルチメディア](https://www.johoka.jp/digital#h.9uo4whoso8hx)<br>

### 3.基礎理論
- 基数変換**<br>
- 補数と固定小数点<br>
- [浮動小数点](https://tamotech.blog/2023/05/02/%e3%80%90ieee754%e3%80%91%e6%b5%ae%e5%8b%95%e5%b0%8f%e6%95%b0%e7%82%b9%e3%81%ae%e8%a1%a8%e7%8f%be%e8%a6%8f%e6%a0%bc%e3%81%a8%e3%81%9d%e3%81%ae%e5%a4%89%e6%8f%9b%e6%96%b9%e6%b3%95/)<br>
- 誤差<br>
- シフト演算*<br>
- 論理演算**<br>
- 半加算器と全加算器<br>
- [計測と制御](https://www.johoka.jp/digital)**<br>
- オートマトン*<br>
- AI**<br>
- 線形代数*<br>
- 確率統計**<br>

### 4.アルゴリズムとプログラミング(B)
- アルゴリズム**<br>
- 配列**<br>
- リスト*<br>
- キューとスタック**<br>
- 木構造*<br>
- データの整列*<br>
- データの探索*<br>
- アルゴリズムの計算量<br>
- プログラムの属性*<br>
- プログラム言語とマークアップ言語*<br>

### 5.システム構成要素
- [システム構成](https://tamotech.blog/2022/12/04/system-configuration/)*<br>
- [クライアントサーバシステム](https://tamotech.blog/2022/12/12/crient-server-system/)*<br>
- [RAIDと信頼性設計](https://tamotech.blog/2022/12/30/raid-level/)*<br>
- システムの信頼性設計*<br>
- システムの信頼性評価**<br>

### 6.データベース技術
- データベース*<br>
- データベース設計*<br>
- データの正規化*<br>
- [トランザクション処理](https://tamotech.blog/2023/01/14/data-transaction-consistency/)**<br>
- [データベースの障害回復](https://tamotech.blog/2023/01/15/roll-forward-and-roll-back/)*<br>
- データ操作とSQL**<br>
- SQL(並べ替え・グループ化)*<br>
- SQL(副問合せ)<br>
- [データベースの応用](https://tamotech.blog/2023/01/28/nosql/)*<br>

### 7.ネットワーク技術
- [ネットワーク方式](https://www.foresight.jp/fe/column/lan-wan/)*<br>
- [通信プロトコル](https://zenn.dev/itpassport/articles/03bd090fa135ba)*<br>
- [ネットワーク接続機器](https://qiita.com/pieceofmysoul1225/items/fb42aeceb0b423e1895d)**<br>
- [IPアドレス](https://zenn.dev/itpassport/articles/acefa57f6d2b76)**<br>
- [IPアドレスのクラス](https://qiita.com/pieceofmysoul1225/items/b75f5d00ca40de49b8b8)**<br>
- [ネットワーク管理とインターネットの応用](https://qiita.com/pieceofmysoul1225/items/143c3c743bca15d65625)*<br>

### 8.情報セキュリティ(B)
- 情報セキュリティと情報セキュリティ管理**<br>
- 脅威とマルウェア**<br>
- サイバー攻撃**<br>
- 暗号化技術**<br>
- 認証技術**<br>
- 利用者認証とネットワークセキュリティ**<br>

### 9.システム開発技術
- 情報システム戦略とシステム企画*<br>
- ソフトウェア開発**<br>
- オブジェクト指向**<br>
- 業務モデリング*<br>
- ヒューマンインターフェース*<br>
- モジュール分割<br>
- テスト手法*<br>

### 10.マネジメント系
- プロジェクトマネジメント*<br>
- 工程管理*<br>
- ITサービスマネジメント*<br>
- システム監査**<br>

### 11.ストラテジ系
- ソリューションビジネスとシステム活用促進**<br>
- 経営組織と経営マーケティング戦略*<br>
- 業績評価と経営管理システム<br>
- 技術開発戦略<br>
- ビジネスインダストリ**<br>
- 品質管理<br>
- 会計財務*<br>
- 知的財産権とセキュリティ関連法規**<br>
- 労働・取引関連法規と標準化*<br>
- オペレーションズリサーチ<br>

※ youtubeで解説してくれている人がいたので、何かわからない事があれば見てください<br>
https://www.youtube.com/@kihonzyouhou/videos

## 攻略方法について
### 基礎的なIT知識をおさえる
基本情報技術者試験の勉強を効果的にするには、まず基礎的なIT知識をおさえましょう。<br>
基礎的なIT知識が身についていなければ、先に進んでも理解が深まりません。<br>
はじめて基本情報技術者試験の勉強をする人は、テキストを何度も読み、用語の意味を理解して、基礎をしっかり身につけましょう。テキストを読むごとに、基礎知識は定着していきます。<br>

### 過去問題を繰り返し解く
基本情報技術者試験の勉強は、過去問題を繰り返し解くことも大切です。<br>
「科目A 試験」の勉強には、変更前の午前試験の過去問題を活用できるため、繰り返し解いて試験対策をしましょう。<br>
できるだけ多くの過去問題を解くことで有利になります。<br>
過去に何度も繰り返し出題されている問題は、重要な問題であることが多いため試験対策に活かしましょう。<br>

「基本情報技術者過去問道場」の活用<br>
https://www.fe-siken.com/fekakomon.php<br>
解説も出てくるので、理解しやすい！<br>

## まとめ
50~100時間くらい勉強時間を確保しましょう。<br>
あとは、集中するだけです。<br>

ちょっと難しいなと思う人は、難易度の低い「ITパスポート試験」を受験してみてもいいかもしれません。<br>

9784297131302.jpg

【基本情報技術者試験】効率的な攻略方法について

## はじめに

2023 年には、CSS にいくつかの新しい機能が追加されましたので　このブログでは、2023年の新しいCSSの機能について紹介したいと思います。

最新のCSS技術や仕様は、ウェブページが早く読み込まれ、表示される速さや効率を良くすることを目指しています。

新しいCSSの機能やツールは、開発者がコードをより効果的に書き、管理するのに役立ちます。

Web 開発者は、より個性的で魅力的な Web ページを作成できるようになります。
すべてのブラウザでサポートされているわけではありません。ただし、ほとんどの主要なブラウザでは、これらの機能がサポートされています。

今回以下の新しい　CSS について説明します。

1. inset
2. Accent-color
3. Gap Property for Flexbox
4. -webkit-line-clamp
5. Small Viewport Units(svh)
6. Transform Properties

## 1. inset

CSS insetは、要素をその親要素の端に対して配置するためのプロパティです。通常の配置ではなく、要素が親要素からはみ出るようなデザインを作成する際に便利です。

**前**
```
element {
  top: 80%;
  right: auto;
  bottom: auto;
  left: 50%;
}
```
このコードはtop、right、bottom、left の各プロパティを個別に指定しています。

**現時**
```
element {
  inset: 80% auto auto 50%;
}
```
現時は inset プロパティを 使て　1 行で指定できるようになりました。

**Browser Support**

 ![](https://cont.sterfield.co.jp/uploads/inset_browser_support_69d35a4768.png) 


## 2. accent-color

accent-colorプロパティとは、ラウザが提供するデフォルトのフォーム要素（チェックボックスとラジオボタンとか）の背景色を変更することができるものです。ただし、このプロパティを使用すると、フォームの見た目はブラウザによって統一的に管理されるため、その点に注意が必要です。accent-colorは、2023年からすべてのブラウザにサポートされました。


**html**
```
<input type="checkbox" class="custom" checked />Checkbox
```

**css**
```
.custom{
  accent-color: yellow;
}
```

***Result***

 ![](https://cont.sterfield.co.jp/uploads/checkbox_result_c9839aff27.png) 

**Browser Support**

 ![](https://cont.sterfield.co.jp/uploads/accent_color_browser_support_4483e6b598.png) 


## 3. Gap Property for Flexbox

Gap プロパティは、flexbox レイアウトで各アイテムの余白を指定するプロパティです。
余白を指定すると　margin も使う人が多いですが、gap と　margin の違いがあります。

**Gap**
* flexbox レイアウトでのみ使用できます。
* 単一の値または 2 つの値で指定できます。
  ```
  gap: 10px;/* 行と列の両方に同じギャップ */
  gap: 10px 20px;/* 行に10px、列に20pxの異なるギャップ */
  ```
* 余白を指定すると、最初と最後の要素余白も範囲されません。
  :not()や:nth-childなどの擬似クラスを使用する必要がなく、CSSのコードがシンプルになります。

**Margin**
* 任意のレイアウトで使用できます。
* 単一の値、2 つの値、または 4 つの値で指定できます。
  ```
  margin: 10px;/* すべての辺に同じマージン */
  margin: 10px 20px;/* 上下には10pxのマージン、左右には20pxのマージン */
  margin: 10px 20px 15px 5px;/* 上、右、下、左それぞれ異なるマージン */
  ```
* 余白を指定すると、最初と最後の余白も範囲されます。

**html**
```
<div class="flexbox">
  <div class="flex-item">div1</div>
  <div class="flex-item">div2</div>
  <div class="flex-item">div3</div>
  <div class="flex-item">div4</div>
  <div class="flex-item">div5</div>
  <div class="flex-item">div6</div>
  <div class="flex-item">div7</div>
  <div class="flex-item">div8</div>
  <div class="flex-item">div9</div>
</div>
```

**css**
```
.flexbox {
  display: flex;
  gap: 10px;
  width: 500px;
  flex-wrap: wrap;
  justify-content: center;
}
.flex-item{
  background: yellow;
  width: 30%;
  color: #000;
  padding: 10px 0;
  text-align: center;
}
```

**Result**

 ![](https://cont.sterfield.co.jp/uploads/gap_image_ee5a78ad50.png) 

**Browser Support**

 ![](https://cont.sterfield.co.jp/uploads/gap_browser_support_c840b87e6a.png) 

## 4. -webkit-line-clamp

-webkit-line-clamp は、CSS の属性で、テキストの表示行数を決める機能です。この機能を使うと、テキストの折り返しを管理して、簡潔で読みやすいテキストブロックを作成することができます。

**html**
```
<p class="truncate-text">
    This is a long piece of text that will be truncated after three lines using the -webkit-line-clamp property. This is a long piece of text that will be truncated after three lines using the -webkit-line-clamp property.
</p>
```

**css**
```
.truncate-text {
  display: -webkit-box;
  -webkit-box-orient: vertical;
  overflow: hidden;
  -webkit-line-clamp: 3; 
  width: 200px;
}
```

**Result**

 ![](https://cont.sterfield.co.jp/uploads/webkit_line_clamp_result_b8921f908a.png) 

**Browser Support**

 ![](https://cont.sterfield.co.jp/uploads/line_clamp_browser_support_7a35bf934f.png) 


## 5. Small Viewport Units(svh)

Small Viewport Units (svh)は、ユーザーに表示される最小のビューポートの高さを表す単位です。最小のビューポートの高さは、ユーザーエージェントによってすべてのインターフェース要素が除外されます。
要素の高さを簡単に調整できます。アドレスバーが含まれるため、要素の実際の高さが異なることもあります。

**html**
```
<div id="container">
  <label>Top Full Height Example(svh)</label>
  <p>Bottom Full Height Example(svh)</p>   
</div>
```

**css**
```
#container {
  background-color: green;
  height: 100svh; 
  position: relative;
}
p{
  position: absolute;
  bottom: 0;
}
label{
  position: absolute;
  top: 0;
}
```
上記の　コード によると　divの高さを 100svh としているので　モバイルの場合アドレスバーの上に表示するようになりました。

div　の　高さを 100vh とすると　下のテキスト(Bottom Full Height Example(svh))が見えなくなります。

**Result**

 ![](https://cont.sterfield.co.jp/uploads/svh_7979a9aefa.png) 

**Browser Support**

 ![](https://cont.sterfield.co.jp/uploads/svh_browser_support_f32c6b0d96.png) 


## 6. Transform Properties

CSS の transform プロパティは、要素の位置、回転、スケール、傾きなどを変更するために使用されます。

**前**
```
.target {
  transform: translateX(50%);
  transform: rotate(50deg);
  transform: scale(1.5);
}
```
このコードは、3 行にわたって、translateX()、rotate()、scale() の各関数を指定しています。

**現時**
```
.target {
  transform: translateX(50%) rotate(50deg) scale(1.5);
}
```
このコードは、1 行だけで、translateX()、rotate()、scale() の各関数を指定出来るようになりました。

**Browser Support**

 ![](https://cont.sterfield.co.jp/uploads/individual_transfrom_browser_support_4f7d36d0a1.png) 


## まとめ

将来、新しいCSSの機能がますます広くサポートされることで、開発者は安定してこれらの機能を活用できるようになります。
新しい機能を使うと、開発者はもっと効率的に作業できて、コードを書くことがスムーズになるでしょう。

日々のプロジェクト開発において、新しいCSSを取り入れて活かしていきたいです。

ただし、新しいCSS機能を利用する前に、ご希望の機能がブラウザでサポートされているか確認するために、このリンク（https://caniuse.com/ ）から確認してください。

## 参考

* https://www.w3.org/Style/CSS/all-properties.en.html
* https://developer.mozilla.org/ja/docs/Web/CSS


2023 年の新しい CSS 機能

## はじめに
先日、東京ビッグサイトで開催されたGoogle Cloud Next Tokyo '23のDay2に参加してきました。

 ![](/uploads/PXL_20231116_001744341_2_90d59a9df4.jpg) 

全体としては生成AIに関するトピックが盛り上がってましたが、セキュリティに関するセッションもいくつかあり、その中で私は下記のセッションに参加して話を聞いてきました。

- [セルフで行う Google Cloud 環境のセキュリティ チェックの方法](https://cloudonair.withgoogle.com/events/next-tokyo?talk=d2-di-04)
- [Google Cloud のセキュリティ機能、基本のキ｜Security Command Center で実現するリスク管理](https://cloudonair.withgoogle.com/events/next-tokyo?talk=d2-sec-02)

どちらのセッションでもSecurity Command Centerを使うことでGoogle Cloudを安全に運用できるという内容でした。
こちらをもとに本記事では、Google Cloudを利用しているがSecurity Command Centerは使ったことがない人向けに、Security Command Centerを使い始めるための設定方法と簡単な使い方の解説します。

## Security Command Centerとは
Security Command CenterはGoogle Cloud上の脆弱性や脅威となりうる設定を検知してくれるサービスです。

有効化しておくと自動で利用しているサービス、リソースを認識して、それらを対象に設定内容をスキャンしてくれるため運用に負荷がかからないのが特長です。また有償版のプレミアムティアーのみの機能となりますが、ISO 27001やPCI DSSのような業界標準への遵守状況も確認できるなどスキャン以外にも様々な機能があります。

今回は無償版のスタンダードティアーでも利用可能なSecurity Health Analytics機能を使って、Google Cloudの設定ミスの診断を試してみました。

## 実際に適用してみた結果
ありがちなユースケースとして、組織の管理権限はもってないが開発環境のプロジェクトだけ変更権限だけを持つユーザーが、Security Command Centerを使ってプロジェクトの脆弱性を診断してみるというシナリオでやってみました。

1. Security Command Centerの有効化
  - まず最初にコンソールでプロジェクトを選択した状態でSecurity Command Centerを開いて有効化を行います。スタンダードとプレミアムの2つのティアーを選択する画面になるので、無償版であるスタンダードを選んで次へを押します。すると、どの機能を有効化するか設定するダイアログが表示されます。すべてデフォルト値のままで進めます。

     ![](/uploads/249ce2bfaa98636550da620a_d3f7f1273a.png) 
      (引用：https://zenn.dev/cloud_ace/articles/scc_standard#security-command-center(%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%80%E3%83%BC%E3%83%89)%E3%82%92%E6%9C%89%E5%8A%B9%E3%81%AB%E3%81%97%E3%81%A6%E3%81%BF%E3%82%8B)

  - 詳細な手順は公式ドキュメントで解説されているのでそちらを参照してください。
  https://cloud.google.com/security-command-center/docs/activate-scc-for-a-project?hl=ja#project-activation-scc-inactive-in-org

2. 診断結果の確認
  - 設定が完了すると自動で脆弱性のスキャンが行われますが、初回のスキャンは少し時間がかかります。今回の例だと24時間ほど待つ必要がありました。
  - 完了するとダッシュボードにスキャン結果が表示されます。脆弱性ページで脆弱性の種類、件数などが確認できます。

     ![](/uploads/scc_1_762224c8e4.png) 
    

3. 脆弱性の対応
  - ここではデフォルトのまま使っていると必ず検出されるOpen RDP portを対象として、実際に対応する場合の流れを解説します。

  - 詳細を開くと脆弱性の詳細や、対象のリソースの情報が確認できます。更に次のステップのところに対応方法が示されます。
    ![](/uploads/scc_2_0a09b3e035.png) 

  - それに従って、ファイアウォール ルールのdefault-allow-rdpの設定を変更します。IPの範囲が0.0.0.0/0がまずいとのことなので削除して35.235.240.0/20を設定します。
     ![](/uploads/scc_3_4f9c670868.png) 

  - なお、ルール自体を無効にしてしまえばIP範囲は変更しなくてよさそうに思えますが、この対応ではだめでした。脆弱性の判断基準としてルールが無効かどうかは関係ないようです。現時点で実害があるかどうかではなく、潜在的な脆弱性として指摘しておくポリシーなのかもしれません。

4. 対応結果の確認
  - 初回スキャンと同様に対応後の確認も特に操作は不要で、自動で再チェックが行われて脆弱性ページの件数が1=>0になります。初回スキャン時と異なり、設定変更後の再スキャンはほぼ即時反映のようで数分後には対応済みになりました。
  - 対応済みの脆弱性を確認したい場合、脆弱性ページ上からは見られなくなってしまいますが、検出結果ページのクエリ編集画面で下記のとおりクエリを変更すると確認可能になります。
    ```
    変更前）
    state="ACTIVE" AND NOT mute="MUTED"

    変更後）
    state="INACTIVE" AND NOT mute="MUTED"
    ```
     ![](/uploads/scc_4_19e81badad.png) 

## まとめ
- Security Command Centerは有効化するだけで特に設定も不要かつ無料で始められるので、使ってみることをおすすめします。
- 検出された脆弱性ごとの対応方法まで案内されるので非常に親切だが、今すぐ対応すべき問題かどうかは利用者自身が判断する必要があります。そのため、まったく知識がない状態で運用することは難しそうです。これについてはGoogle側でも課題と考えているようで、Duet AIによる支援機能が現在開発中とのことです。
- 組織単位でSecurity Command Centerの有効化を行うことで、アカウントの設定不備のようなプロジェクトをまたがった設定内容もスキャン対象となるため、より効果的な運用ができそうです。今回の検証結果をもとに、全社的にSecurity Command Centerを利用する方針を検討していきます。

## 参考リンク
- [Security Command Center](https://cloud.google.com/security-command-center?hl=ja)
- [Security Command Center でお手軽セキュリティ診断](https://zenn.dev/cloud_ace/articles/scc_standard)
- [[Google Cloud] SCC -Security Health Analytics-を試す](https://qiita.com/khoshina/items/f6ccea548e9ed39cdea8)


security-command-center.440x512.png

Security Command Centerを使ってGoogle Cloudの設定内容を診断してみよう

### 書籍の情報
- 書籍名: TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発
- 著者: 手島拓也、吉田健人、高林佳稀
- 出版社: 技術評論社
- ISBN-13: 978-4297129163
- 発行日: 2022/7/25
- リンク: https://gihyo.jp/book/2022/978-4-297-12916-3

## はじめに
「TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発」は、開発をより快適・堅牢にするTypeScriptを用いて、React/Next.jsの基礎、最新フロントエンドやWebアプリケーションの開発方法が学べる書籍です。

TypeScriptは、JavaScriptのスーパーセットであり、型システムを備えたプログラミング言語です。型による静的チェックにより、プログラムの欠陥をコンパイル時やデバッグ時に検出することができます。これにより、バグの早期発見や、コードの保守性の向上につながります。TypeScriptはWebアプリケーション、Node.jsアプリケーション、モバイルアプリケーションなどのさまざまなプラットフォームで利用されており、特に大規模で複雑なプロジェクトの開発に適しています。開発者が型安全なコードを書くのを支援し、コードの保守性を向上させるために広く採用されています。

Next.jsは、フルスタックのWebアプリケーションを構築するためのReactフレームワークです。設定に時間を費やすことなく、アプリケーションの構築に集中することができるよう設計されています。Next.jsは、Reactアプリケーションを開発するためのツールセットやサーバーサイドレンダリング（SSR）および静的サイト生成（SSG）の機能を提供し、それらの機能により、SEOの向上、パフォーマンスの向上、セキュリティの向上など、多くの利点を提供します。従って、多くのウェブ開発者によって採用され、高品質のウェブアプリケーションの開発に役立っています。

## こんな方におすすめ

- モダンなWebフロントエンドに興味のある方
- React/Next.jsを初めて使う方、本番に導入したい方
- React/Next.jsとTypeScriptを組み合わせた開発スタイルに興味のある方
- TypeScriptを中心に据えたWebフロントエンド開発に興味のある方
- Atomic DesignやStorybookなど、コンポーネント中心の開発に興味のある方

## 目次

1. Next.jsとTypeScriptによるモダン開発
2. TypeScriptの基礎
3. React/Next.jsの基礎
4. コンポーネント開発
5. アプリケーション開発1〜設計・環境設定〜
6. アプリケーション開発2〜実装〜
7. アプリケーション開発3〜リリースと改善〜
- Appendix Next.jsのさらなる活用

## 各章について

### 1~3章

1章では、Next.jsやTypeScriptを使用したモダンなフロントエンド開発の概要と歴史を紹介しています。歴史の説名を踏まえ、Next.jsの機能に絡めてSSRやSSGの紹介やその必要性に関する説明もされています。

2章では、TypeScriptの基本的な使い方や重要な型について説明されています。また、設定やツールのセットアップについても触れられています。

3章では、Reactの基本的なコンポーネントやフックの書き方やNext.jsの機能の使い方が紹介され、再レンダリングの防止など重要なポイントもカバーされています。

### 4章

この章ではデザインシステムの設計方法であるAtomic Designが紹介され、ReactコンポーネントもAtoms, Molecules, Organisms, Templates, Pagesの5レイヤーに分類することが推奨されています。Atomic Designとあわせて、ファイル分割やコンポーネント設計の参考になるPresentational Component（見た目）とContainer Component（振る舞いロジック）についても説明されました。
あと、styled-componentsスタイルライブラリから、Storybookでのコンポーネント管理、React Testing Libraryでのコンポーネントテストまで、コンポーネント開発のために使われる一連のツールの使い方が説明されています。

### 5~7章、付録

後半からはアプリケーション開発の実践になります。

5章では主にアプリケーション開発に向けての環境構築を行います。Next.jsや前の章で説明があったstyled-components、StorybookとESLintのセットアップとReact Hook Formをはじめ、SWRとMaterial Icons、React Content Loaderなどさまざまなライブラリやツールの導入が紹介されます。

6章は、総435ページで150ページほど占めて本のメイン部分ですが、ほぼコードに構成されていて間に簡単な説明が入ります。まずは、Atomic Designに従って各ページをコンポーネントコンポーネントへと分割して、一番小さい部品であるAtomsから実装していきます。次のMolecules実装も特にロジックを持たないようにしています。Organisms, Templates, Pagesについても同様の構成で進みます。Pagesからは4章にあったPresentational ComponentとContainer Componentの見た目とロジックを別ファイルに分ける方法で実装していきます。加えて、React Testing LibraryでAtoms, Molecules, Organismsレイヤーのユニットテストを書きます。

7章では、まず、5章と6章でつくったアプリケーションをVercel, Heroku, Logflareといったサービスにデプロイする方法の説明されており実際にデプロイして見るのができます。また、SEO対策として、構造化データをページに付与する方法やOGP、sitemap.xmlの生成などを取り扱います。さらに、アクセシビリティ、XSSとかCSRFのセキュリティの説明もされています。

付録には外部サービスの連携活用など、さまざまな内容が説明されています。これらの内容は現場にも役立ち、読者にとって嬉しい情報となっています。

## 感想

既に探り探りでTypeScriptとReact/Next.jsで開発していましたが、本書を読んでから、TypeScriptとReact/Next.jsの組み合わせでの開発経験が浅い私にとっては、良い見本になりました。

本書は、全般的にわかりやすく、実践的な内容で、概観を掴めることができて満足しています。
また、さまざまなライブラリを取り入れて使用できてみたのも、良い点でした。例えば、Next.jsと同じチームで作られているデータ取得のためのReact HooksライブラリであるSWRやローディングを表示するライブラリReact Content Loaderは初めて使用してみて今後の開発にも良い選択肢になると思いました。

ただ、もうちょっと具体的な説明や使う理由などがあったらよかったなと思った部分もありました。例えば、ライブラリの使い方の説明では、なぜそのライブラリを使うのか、そのライブラリのメリットやデメリットなどについて、もう少し詳しく説明があると、理解しやすかったでしょう。

とはいえ、本書は、TypeScriptとReact/Next.jsの両方を学びたい人にとって、最適な入門書であることは間違いありません。本書を参考にして、TypeScriptとReact/Next.jsの開発スキルを磨き、実践で役立てていきます。

以上、『TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発』についての紹介でした。もし、TypeScriptとReact/Next.jsの組み合わせで実際動かしてみながら学びたい方には、ぜひおすすめの一冊です！

TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発

book.png

【書籍紹介】TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発

先日、弊社で運営しているコンペナビで、「自治体向け動画コンテスト主催サポートプラン」というLPを作成し公開しました。  
  
<a href="https://compe.sterfield.jp/lp_jichitai" target="_blank">コンペナビ　自治体向け動画コンテスト主催サポート</a>  

私はこのLP制作につき、デザイナーとコーディングを担当し作成しました。  

この案件は弊社の社内案件であり、若手の営業担当がディレクションを行い、私が制作という関係で進めました。

最終的に納得のいく物が作成できましたが、振り返ってみると、企画段階でもっと詰めるべきことがあったし、ディレクターと作業者の間でどこまでが自分が主導して進めるべきか？を悩み、時にはお互いに担当分野を越境したような動きがありました。  

また、社内の関係者間でも、相談するべき点がありました。  
この案件を通して、改めてディレクションの大切さを実感し、反省を兼ねてブログに残します。


## プロジェクトのスタート

当初私のもとには図1の形でまとめられたワイヤーを渡されました。  

図1
<img src="/uploads/20231020_1_16304a854a.png" alt="企画書第一段階">

ワイヤーのコンテンツを大まかなに分けると以下の内容となっていました。  

第1要素　（メインビジュアル要素）
・キャッチコピー
・コンペナビの強み（3点）
・メインビジュアル
・お問い合わせへのリンク

第2要素　
・動画コンテストを開催する意義とサポートする旨の文章
・具体的なサポート内容を示すアイコン

第3要素　
・コンペナビの強み５点を強調する旨のコンテンツ

第4要素　
・コンペ開催のフローと料金について（コンペナビの内容のコピー）

第5要素
・実績

第6要素（最下部）
・お問い合わせフォーム


そして、  
・デザインはコンペナビと関連ある物。コンペナビの下層ページのようなイメージでコンペナビのコンテンツだとわかるものにしてほしい。  
・コンテンツの内容はワイヤーの内容にしたい。  
・この案で上長からGoサインが出ているから進めてもらいたい  

という話をいただきました。  

率直に私が思ったことはまだ、ワイヤーとして完成していないと感じました。 そこで先ず私はディレクターと話し、コンテンツを整理しなおしました。

私は主に  
・メインビジュアルに要素を詰め込みすぎ。  
・メインビジュアルのコンペナビの強み（3点）もこれだけで1つのコンテンツとして成立するし、補足的に見せる内容ではない。  
・全体的にテキストが多い。ビジュアルで見せる部分とテキストで説明する部分を意識した方が良い。  
・第3要素のコンペナビの強みもリズミカルに見せるなら3つくらいに絞った方がよい。  
・補足したい説明があれば、よくある質問というコンテンツにしてQ＆A方式で解説すれば見栄えもよい。  

と言う点を指摘しました。  

そこで、私とディレクターの間でワイヤーを作り直す作業が始まりました。  
このやり取りはプロジェクトを進める上で別に間違ってはいなかったでしょう。  
ただ、デザイナーの私がどこまで口を出すべきか悩みました。  


### 反省点：  
・デザイナーに話を持っていく前に、もっと詰めるべき点があったのでは？  
・制作部としては私がデザイン作業をしていると思っていた。役割を明確にするべきだった。  



## ワイヤー完成からデザイン完成迄

私はワイヤーの内容を大まかにレイアウトし、画面の構成を作る作業をしました。まだ、コンテンツについて考える余地もあり、
なるべくビジュアル要素を増やしてテキスト量を減らすこと、言い回しや見せ方を工夫することで省略できる点はないか、
コンテンツの順番を変えることでよりインパクトが出る見せ方にならないか？などの点を工夫して作成をしました。  


そして、何か思いつけば図2のように実際に簡易的なサンプルを作って、ディレクターに提案するという流れで作業を進めました。
こうして同意を得て、細部まで含めて作成する作業に入りました。  

図2
<img src="/uploads/20231010_2_7c3fe1e73b.png" alt="気可食第一段階">



このとき、デザインはコンペナビを踏襲してほしいという要望を聞いていたので、コンペナビの色使いやアイコンの使い方を見てそれに
よせる作業をし図3の形でまとめました。  


図3
<img src="/uploads/20231020_3_5982681709.png" alt="図3">

そして、私及びディレクター双方が納得し、コーディング開始の段階になりましたが、この段階で上長に確認をいただきました。 
  
この時頂いた意見は、    
・実績をもっと前面に打ち出す形の方がいい。  
・コンペナビの強みという点が取ってつけたように見える。  
・動画コンテストを開く意義について言っているコンテンツが少ない。  
  
というものでした。 

私は当初のワイヤーがテキストが多く、すっきり見せることを意識していた。しかし、この意識を強くしたため、必要であった要素を作業の過程で削っていました。
結果、このデザイン案は作り直しとなったのですが、相談するべきタイミングは明らかに間違えてしまいました。


### 反省点：
・作業を進める段階で完成像の指針がぶれてしまった。  
・部署内で相談するべきタイミングをもっと増やすべきだった。  


## 仕切り直しから完成まで

結局案件は、ディレクター側で再度ワイヤーから作り直すという話になり、2週間くらい経過したらディレクターから新しいワイヤー（図4）が渡されました。
ほぼ、最終系に近い形でいただきました。  

図4
<img src="/uploads/20231020_4_4c7ec1839f.png" alt="図4">

そして、ディレクターが参考にしたWebサイトのURLと一緒に渡され、この形で作り細部はコーディングをしながら直してほしい。
と言われてコーディング作業開始に至りました。  

ここまで完成されたものを渡されたら、デザイナー側でビジュアル要素を作る作業はほぼありませんでした。ただ、これをコーダー目線で見た場合、設計図としては
足りていない点があります。
例えば、  

・メインビジュアルはリキッドデザインになっているが、その他のコンテンツは幅が想定されていない。  
・コーディングで再現するのは難しい部分がある。  
・レスポンシブデザインを意識したとき、レイアウトの変化を意識していない。  

なので、画像の切り出し方に困ってしまったり、作りなおしになった部分もありました。
また、参考にしたWebサイトを見ると、スクロールしてコンテンツが表示されると簡単なアニメーションと共に表示される仕掛けが（フェードインするなど）がありました。  

これを導入するかディレクター側では答えを持っていませんでした。なので、私は「動画」を扱っている以上、動きのある演出の方が良いと提案し、動きを入れるようにしました。  

このような形で導入が決まったのでレイアウト構成の作業をしながらアニメーションを追加し、私の感覚で単調にならないように工夫しながら実装しました。
このため、ディレクター側で考える工数より多くの時間が私の作業段階で発生しました。

更に、完成間近のタイミングでコンペナビのページからこのLPにリンクを貼る依頼を受けました。  

ディレクターの指示では、  

・ヘッダー部分にテキストとボタンを設置してほしい。  
・コンペ全般の主催をすることを進めるページにリンクするボタンを設置してほしい  

という物でした。  
ヘッダー部分は問題なかったのですが、後者の依頼は、意図を聞いてみると新サービスなので、関連項目として見せたいとのことでした。  

このような意図であるならば、ボタンではテキストの説明が必要になるし、テキストを書けばページ本来の趣旨を妨害してしまう。だからバナーの形にするべきと説明しました。  
結果、バナー制作という想定してないコストもかかることになりました。



### 反省点：  
・コーダーに依頼するのであれば、このような形のワイヤーでよいが、デザインも含めて依頼するなら作りすぎている。  
・コーディング開始前に実現できるか検討した上で作業に入るべきだった。  
・コーダーに渡すワイヤーなら、動的なイメージについてどのようにするかも含めて検討して渡すべきだった。  
・全体的な見積もりがそもそも甘い。  


## まとめ
今回の案件はディレクター側も私のスキルを知っているという前提での依頼の仕方になっています。また、制作部としても比較的にリソースを割けるタイミングだから、着手したものでした。  
しかし、社内案件でも、社内の人を使うから無尽蔵に使える物ではありません。
      
成果物としては良い物が作れましたが、全体的に多くのコストをかけてしまいました。この点については、企画段階でチーム全体での相談が足りなかったことに原因があります。  
今後はもっとコミュニケーションを取り、よく相談しながら業務にあたっていきます。




3909820_m.jpg

制作するにあたりディレクションの重要性を改めて感じたこと 

## はじめに
Reactでフロントエンドの開発を行う場合に、おそらく一度は誰でも状態管理に頭を悩ませるのではないでしょうか。  
2023年10月現在、Redux、React Hooks、zustand、そしてここで取り上げる Recoil、Jotai など、Reactの状態管理をするためのライブラリや方法は数多く存在ます。  
多くの開発者によりその使い方が模索・洗練されていますが、絶対的な正解というものは存在しません。  
故に、プロジェクトに導入する場合に、どれを選定するかで、とても迷う方は多いのではないでしょうか。  
このブログでは、私が状態管理のライブラリを選定するときに悩んだ内容から、案件の向き不向きについて考察し、ご紹介したいと思います。  

## まず Redux、zustand と Recoil、Jotai の違いについて
Redux は、Reactを作ったFacebookが提唱した[Flux](https://github.com/facebookarchive/flux/tree/main/examples/flux-concepts)というアーキテクチャをもとにした、初期から最も利用されている状態管理ライブラリです。  
Reactとは切り離して１つのストアに集約して管理するため、情報の流れが一方通行で辿りやすい特徴があります。WEBアプリ全体の一貫性を重視し、堅牢な作りにする場合、Reduxは有望な選択肢となります。  
しかしながら、Reduxは非同期通信を伴うような複雑な状態管理ではそのまま使うのはあまりにもコードが膨大になってしまうため、サードパーティのプラグインなどを導入することが現実的な選択肢となります。また、1つのストアで管理するため、コンポーネント単位でのカプセル化が苦手です。  
  
zustand はこのReduxの苦手な部分を補うことで、Reduxからの乗り換えが進んでいるライブラリです。  
基本的な思想はReduxと同じですが、Reduxで煩雑になるような記述をより簡潔に書くことができます。 
  
Recoil は Redux とは違う思想で、ストアを複数持ち、それぞれに対して別々のコンポーネントからアクセス可能です。ストアが一元管理されているReduxやzustandとちがい、コンポーネント単位でのカプセル化がしやすく、データとアプリ全体の結合を制限することに向いているので、柔軟性を重視するアプリに向いていると言えそうです。
ただ、複数のストアに別々のコンポーネントから双方向でアクセスできる特徴が故に、組み方によってはReduxと比べると情報の流れを辿りにくくなる可能性があることに注意が必要です。  
  
Jotai は Recoil をより簡潔に記述できるようにしたライブラリで、[npm trends](https://npmtrends.com/Jotai-vs-react-redux-vs-recoil-vs-zustand)を見ると、2023年10月現在、本家のRecoilを追い抜いています。  

## RecoilよりJotaiが向いている案件
RecoilとJotaiで同じ状態管理をするためのコードを比べてみましょう。
#### Recoil
```typescript
const exampleState = atom({
  key: "exampleState",
  default: 0
});
const exampleSelector = selector({
  key: "exampleSelector"
  get ({ get }) => `${get(exampleState)}個を選択中`
});
```
#### Jotai
```typescript
const exampleState = atom(0);
const exampleSelector = atom((get) => `${get(exampleState)}個を選択中`);
```
こうやって並べてみるとよく分かりますが、  
Jotaiの方が圧倒的にコード数が少なくなります。  
Recoilで用意されている機能の多くはJotaiでも利用できるので、よりシンプルに状態管理を行いたい場合は、  Jotaiが向いていると言えます。  
  
## JotaiよりRecoilが向いている案件
では、次の場合はどうでしょう。  
#### Recoil
```typescript
// Writable
const idState = atom({
  key: "idState",
  default: 1
});

// Read Only
const fetchState = selector({
  key: "fetchState",
  get: async ({ get }) => {
    const id = get(idState);
    try {
      const response = await fetch(`example.api.json?id=${ id }`);
      const json = await response.json();
      return json;
    } catch (error) {
      throw error;
    }
  }
});

// Writable (default value fetched)
const complexState = atom({
  key: "complexState",
  default: selector({
    key: "complexSelector",
    get: async ({ get }) => {
      const json = await get(fetchState);
      return {
        id: json.id,
        name: json.exampleName
      }
    }
  })
});
```
#### Jotai
```typescript
// Writable
const idState = atom(1);

// Read Only
const fetchState = atom(async (get) => {
  const id = get(idState);
  try {
    const response = await fetch(`example.api.json?id=${ id }`);
    const json = await response.json();
    return json;
  } catch (error) {
    throw error;
  }
});

// Writable (default value fetched)
const defaultComplexState = atom(async (get) => {
  const json = await get(fetchState);
  return {
    id: json.id,
    name: json.exampleName
  }
});
const overWrittenComplexState = atom(null as { id: number; name: stirng; });
const complexState = atom<number, [number], void>(
  async (get) =>
    (await get(overWrittenComplexState)) ||
    (await get(defaultComplexState)),
  (_get, set, update) => set(overWrittenComplexState, update)
);
```
このように初期値をフェッチしつつ、後からデータの上書きもできるようなストアを作ろうとするような複雑な処理をさせようとした場合、JotaiよりRecoilの方が分かりやすいコードになることがわかるかと思います（もっと上手な書き方があったらすみません）。  
また、フェッチしたデータをリセットできるようにする場合、  
  
#### Recoil
```jsx
const exampleState = atom({
  key: "exmapleState",
  default: 0
})
const ExampleComponent = () => {
  const [example, setExample] = useRecoilState(exampleState);
  const reseter = useResetRecoilState(exampleState);
  const handleAddClick = () => setExample(previousState => previousState + 1);
  return (
    <div>
      <p>{example}</p>
      <button onClick={handleAddClick}>追加</button>
      <button onClick={reseter}>リセット</button>
    </div>
  )
}
```
のように、Recoilはatomに対してそのままuseResetRecoil()を使うことでリセット可能ですが、  
  
#### Jotai
```jsx
const exampleState = atomWithReset(0);
const ExampleComponent = () => {
  const [example, setExample] = useAtom(exampleState);
  const reseter = useResetAtom(exampleState);
  const handleAddClick = () => setExample(previousState => previousState + 1);
  return (
    <div>
      <p>{example}</p>
      <button onClick={handleAddClick}>追加</button>
      <button onClick={reseter}>リセット</button>
    </div>
  )
}
```
のように、Jotaiでは、あらかじめreset用のutil（atomWithRest）を使ってatomを用意する必要があります。  
その他にも、Jotaiでは複雑な操作をしようとした場合に、Recoilと同様の操作をするためにより多くのutilを使ったり、helperを自前で用意しなければいけない場合に遭遇します。  
  
これらのことから、より複雑なデータ処理を扱うような使い方をする場合、Recoilの方が向いていると言えます。  

## まとめ
堅牢でアプリ全体を見通すことを優先するのであれば Redux。  
基本的な思想はReduxと同じだけど、よりシンプルに描きたいのであれば zustand。  
機能追加やコンポーネントの入れ替えが多いような柔軟性のあるアプリで、複雑なデータ管理が必要なら Recoil。  
柔軟性とシンプルさを重視するなら Jotai というのが、現時点での自分の選択基準でした。

## 参考リンク

- [Jotai](https://jotai.org/)
- [Recoil](https://recoiljs.org/)
- [Redux](https://redux.js.org/)
- [zustand](https://github.com/pmndrs/zustand)
- [npm trends: jotai vs recoil vs redux vs zustand](https://npmtrends.com/jotai-vs-recoil-vs-redux-vs-zustand)

20231006_1.png

Reactの状態管理ライプラリはRecoilとJotaiならどちらをえらべばいいか？

ツイートのいいね数やコメント数、YouTubeの投稿日時、Amazonなどネットショップのレビュー数、通貨ごとの適切な価格表示など、UX（ユーザーエクスペリエンス）の向上やコンテンツや商品の競争力を高めるためには、これらの数字をユーザーが一目で理解できるようにすることが一つのポイントになります。

また、数字が非常に長い場合は、簡潔に表示する方が読みやすいです。さらに、ユーザーの使用言語や文化に合わせて、数字を適切に表示することが良いでしょう。

上のように数字、日付、価格を簡潔に表示するために、外部ライブラリを使用せずに、JavaScript標準仕様にあるIntl APIを使用するとより簡便に実装できます。

### Intl API
**Intl** APIはinternationalization（国際化）APIの略で、下記はMDNからの引用です。

> **`Intl`** オブジェクトは、 ECMAScript の国際化 API の名前空間で、言語に依存した文字列の比較、数値の書式化と、日付の書式化を提供します。 **`Intl`** オブジェクトは、いくつかのコンストラクターに加え、国際化コンストラクターや他の言語に関する関数に共通する機能へのアクセスを提供します。
> 

また、internationalizationは始めのiから終わりのnまでの間に18文字入っていることで**i18n**と呼ばれています。

ほとんどの最新のブラウザでサポートされているため、互換性を心配せずに使用できます。

では、いくつかの使い方を紹介します。

## 数字を簡潔に表示
`Intl.NumberFormat`を使用します。
viewsに閲覧数を表す数字を入れています。このように大きな数字をそのまま表示すると読みにくくなります。
最初の引数には言語を指定するだけで良いので、日本語の場合は`ja-JP`を指定します。
```
const views = 9741275;
const formatter = new Intl.NumberFormat('ja-JP');

console.log(formatter.format(views));  // 9,741,234
```
より簡潔に表示するには、2番目の引数にさまざまなオプションを指定できます。オプションの中で`notation: 'compact'`を指定するとコンパクトになります。
```
const views = 9741275;
const formatter = new Intl.NumberFormat('ja-JP', {
    notation: 'compact'
});

console.log(formatter.format(views));  // 974万
```
さらに、1番目の引数に言語ブラウザのAPIでサポートされている`navigator.language`を指定すると、ユーザーがブラウザで設定した言語を自動的に取得でき、ユーザーが指定した言語に応じて数字を表示できます。
```
const views = 9741234;
const formatter = new Intl.NumberFormat(navigator.language, {
  notation: 'compact'
});

console.log(formatter.format(views));  // 974万
```
## 価格を通貨に合わせて簡潔に表示
同様に`Intl.NumberFormat`を使用します。
1番目の引数には同じく言語を、2番目の引数のオプションで`style: 'currency'`に設定し、currencyオプションで通貨`currency: 'JPY'`を指定します。
```
const price = 1000000;
const formatter = new Intl.NumberFormat('ja-JP', {
  style: 'currency', 
  currency: 'JPY'
});

console.log(formatter.format(price)); // ￥1,000,000
```
ここでも"compact"オプションを使用してコンパクトにすることができます。compactオプションは価格よりはいいねの数など大体の数を表す時にいいかもしれません
```
const price = 1000000;
const formatter = new Intl.NumberFormat('ja-JP', {
  style: 'currency', 
  currency: 'JPY',
  notation: 'compact'
});

console.log(formatter.format(price)); // ￥100万
```
## 相対時間をスマートに表示
商品や記事がいつ公開されたか、何日前、何時間前に投稿されたかを表す必要もあります。相対時間をスマートに表示するためには`Intl.RelativeTimeFormat`を使用します。
`format`の1番目の引数は数字で、2番目には日付か時間か月かなどを指定します。
```
const formatter = new Intl.RelativeTimeFormat('ja-JP');

console.log(formatter.format(1, 'day')); // 1 日後
```
オプションに`numeric: 'auto'`にすると言葉を変えてくれます。
```
const formatter = new Intl.RelativeTimeFormat('ja-JP', {
  numeric: 'auto'
});

console.log(formatter.format(1, 'day')); // 明日
```
入社して何日経ったかを示したい場合、今日を基準にして、入社日の日付を指定し、現在までの日数を計算し、フォーマッタを使用すると、"〜日前”と表示されます。
```
const today = new Date();
const startDate = new Date(2021, 4, 17); // 2021年5月17日　monthは0から始まるため5→4
const daysPassed = Math.ceil((startDate - today) / (1000 * 60 * 60 * 24));
const yearsPassed = Math.ceil((startDate - today) / (1000 * 60 * 60 * 24　* 365));
const formatter = new Intl.RelativeTimeFormat('ja-JP', {
  numeric: 'auto'
});

console.log(formatter.format(daysPassed, 'day')); // 857 日前
console.log(formatter.format(yearsPassed, 'year')); // 2 年前
```
ただし、2番目の引数は日か時間かのどちらか1つだけを指定できます。

この問題を補完できるライブラリ`timeago.js`がありますが、時間がどれだけ経過したかに応じて日か時間かを自動的に表示されるので、相対的な時間のみが必要な場合に便利かと思います。

## 日付と時間を正確に表示
時間を表示するときには、コンパクトにしてより読みやすい場合もありますが、正確な日付を表示する必要があるときもあります。その場合は`Intl.DateTimeFormat`または`toLocalDateString`を使用します。
```
const today = new Date(); // 作成日基準の今日

console.log(today.toString()); // Thu Sep 21 2023 12:05:01 GMT+0900 (日本標準時)
console.log(new Intl.DateTimeFormat('ja-JP').format(today)); // 2023/9/21
```
これをさらに簡略化した方法もあります。
```
const today = new Date();

console.log(
  today.toLocaleDateString('ja-JP', {
    minute: 'numeric',
    hour: 'numeric',
    day: 'numeric',
    month: 'short',
    year: 'numeric',
    weekday: 'short'
  })
); // 2023年9月21日(木) 12:18
```
日付にtoLocaleDateStringを使用するだけで、内部的にはIntl APIを使用するため、より簡単にフォーマットを使用できます。言語を指定するだけでその言語に合わせたフォーマットが表示されます。さらに、さまざまなオプションを指定することもできるので、より簡単にまたはより詳しく表示できます。

### まとめ

IntlはJavaScriptの標準仕様であるので、定期的に更新され常に最新の国際化に向けた実装が可能です。また、外部ライブラリに依存せずに使用できることも良い点です。もちろん一つの言語だけを対応するサイトでも使用でき、その言語に合わせたフォーマットにしてくれるので別途用意しなくて済みます。

日々の開発においても活用していきたいと思います。


#### 参考
- https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Intl
- https://cercopes-z.com/JavaScript/Object-Intl-js.html


【JavaScriptのIntl】数字や日付、価格の表示をスマートに

## はじめに

本記事では、これから TDD の導入を考えている方や、TDD を導入している案件に携わる方に向けて、私が実際に TDD をやってみて感じたメリット・デメリットをまとめたいと思います。

## テストの重要性

テストは、ソフトウェアの品質向上や開発効率化に欠かせないものになってきています。テストを効果的に活用することで、ソフトウェアの品質や信頼性を向上させ、開発コストを削減することができます。

## TDD(テスト駆動開発)とは

テスト駆動開発（Test-Driven Development、TDD）は、ソフトウェア開発の手法の一つで、テストの作成から始めて、その後にコードを実装するというサイクルを繰り返すことで、品質の高いソフトウェアを開発する手法です。
手動テストするのではなく、[Jest](https://jestjs.io/ja/)や[JUnit](https://junit.org/junit5/)などのテストフレームワークを使用します。

一般的な開発では、下図のように設計とテスト作成は分けて行うと思います。

 ![image](/uploads/20230908_2_b6073f3e4b.png) 

TDD では、最初にテストを作成します。
テスト作成 ≒ 設計のようなイメージです。

 ![image](/uploads/20230908_3_11d5709f45.png) 

## TDD の基本サイクル

TDD は「レッド」「グリーン」「リファクタリング」と呼ばれる工程で進められます。各工程で何をするのか、説明していきます。

### レッド

要件から、実装する機能のテストを作成します。この段階では実装をしていないので、テストはすべて失敗します。
テストツールを使っているときにテストが失敗すると赤色でエラー表示されるため、この工程はレッドと呼ばれます。

### グリーン　

レッドで作成したテストをもとに、実装を行います。
ここで重要なのは、完璧なコードを書くことではなく、先に設定したテスト条件を全てクリアさせるだけの「最小限」のコードを書くということです。
テストツールを使っているときにテストが通ると緑色でエラー表示されるため、この工程はグリーンと呼ばれます。

### リファクタリング

すべてのテストが通るようになったら、リファクタリングを行ってコードの可読性を高めます。
この工程は後回しになりがちですが、プログラムの規模が大きくなると大変になってしまうので、こまめにリファクタリングすることをお勧めします。

## TDD のメリット

TDD を実施すると、以下のようなメリットがあります。

### 安心して実装ができる

テスト条件を全てクリアさせるように実装することで、実装漏れやバグの発生を抑制できます。
また、何を実装すれば良いのかはテストを見ればすぐにわかるので、工数の削減が期待できます。

### 品質向上

テストが既にあることで、開発者がコードを変更する際にも、影響を受ける他の部分に対して問題がないかを確認できます。また、テストが十分にカバレッジされている場合、バグやエラーを早期に発見できるため、ソフトウェアの信頼性が向上します。

### ドキュメントとしての役割

テストコードはソフトウェアの仕様や振る舞いを示すドキュメントとして機能します。ソフトウェアの動作がテストによって明確になり、コードの理解が容易になります。
テストコードはソフトウェアの変更に伴って、常に最新の状態に保つ必要があります。そのため、テストコードはソフトウェアのバージョン管理システムに登録し、管理することが一般的です。

### リファクタリングのサポート

リファクタリングを行う前に、テストケースを実行して、リファクタリング後にもテストが通ることを確認することで、ソフトウェアの外部的な振る舞いを保てていることになるため、安全にリファクタリングを行うことができます。
また、リファクタリングで起きがちなデグレ(デグレード)やバグの発生を防止できます。

## TDD のデメリット

TDD は、ソフトウェアの品質向上や開発効率化に効果的な手法ですが、導入にはいくつかの課題があります。

### テストを作るのに時間(工数)がかかる

TDD は、テストコードを先に作成する必要があるため、開発プロセス全体において時間がかかることがあります。
ただし、長期的にはバグの減少や品質向上が見込めることから、開発全体で考えると時間の節約と考えることもできます。

### 熟練度と学習コスト

TDD は、初めて取り組む開発者にとっては学習コストがかかる場合があります。
効果的なテストを作成するためには、適切なテストケースを選択し、適切なカバレッジを持つことが必要です。
しかし、開発の初期段階に完璧なテストコードを書くのは難しいので、今思い浮かぶ機能の中でテストを作成し、仕様変更などのタイミングでより細かいテストを増やしていく方針で進めていました。

### テストの保守

ソフトウェアの変更に伴い、テストコードも頻繁に更新する必要があるため、テストの保守に工数がかかることがあります。
TDD を導入する際にはその負担をチームに理解してもらう必要があります。

## 課題の解決策

TDD の課題を解決するためには、以下のような対策が考えられます。

### テストコードの自動生成ツールを活用する

テストコードの自動生成ツールとは、ソフトウェアの設計や仕様を元に、テストコードを自動的に生成してくれるツールです。
例えば、テストフレームワークに[Jest](https://jestjs.io/ja/)を使用しているのであれば、[jest-test-gen](https://github.com/egm0121/jest-test-gen)などがあります。
テストコードの自動生成ツールを活用することで、テストコードの作成にかかる時間を短縮することができます。

### テストケースの標準化を図る

テストケースの標準化とは、テストケースの作成や評価に使用するルールや手法を定義することです。
テストケースの標準化をすることで、開発者の経験やスキルに依存することなくテストコードを作成できるため、テストコードの作成や保守の効率化を図ることができます。

### チームでのテスト文化を醸成する

チームでのテスト文化を醸成することで、テストの重要性や必要性を理解してもらい、テストへの協力を得やすくなります。

## まとめ

私は気になるところがあるとすぐにリファクタリングしたくなっちゃう性格なので、TDD にはとても助けられています。
TDD は、一見面倒な手法に思われるかもしれませんが、バグの早期発見や仕様の理解、コードの品質向上など、多くのメリットがあります。
メリットとデメリットを理解した上で、適切に活用していきましょう！

## 参考リンク

- [テスト駆動開発（TDD）とは？基本サイクルと運用時の注意点を解説！【ソフトウェア開発・テスト用語 】| Qbook](https://www.qbook.jp/column/713.html)
- [テスト駆動開発（TDD）入門](https://products.sint.co.jp/ober/blog/tdd)
- [テスト駆動開発（TDD）とは？目的やメリット・デメリット、やり方を解説 ｜ソフトウェアテストの SHIFT](https://service.shiftinc.jp/column/4654/)

20230908_1.jpg

TDD(テスト駆動開発)について

Shopeeの商品情報は非常に複雑で、そのため出力できるCSVデータも複雑であり正直わかりやすい状態ではありません。
なので出力できるファイルとその中身についてまとめます。

出力できるファイルは以下の5つです。

mass_update_basic_info
mass_update_sales_info
mass_republish_items
mass_update_shipping_info
mass_update_media_info

それぞれの内容と項目は以下のとおりです。

### mass_update_basic_info
Product ID: Shopeeの商品IDです
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
Product Name: 商品名
Product Description: 商品說明
Fail Reason: 基本的に空欄

### mass_update_sales_info
Product ID: Shopeeの商品IDです
Product Name: 商品名
Variation ID: バリエーションIDです。バリエーションの有無に関わらず値が入ります        
Variation Name: バリエーション名です。バリエーションが2つある場合はセル内にカンマ区切りで2つ入ります     
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
SKU	Price: バリエーションごとの価格です    
Stock; バリエーションごとの在庫です    
Fail Reason: 基本的に空欄

### mass_republish_items
Product ID: Shopeeの商品IDです
Product Name: 商品名
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
Sales: 過去の販売件数
Stock: バリエーションごとの在庫    
Action: ステータスをDelist または Publish
Fail Reason: 基本的に空欄

### mass_update_shipping_info
Product ID: Shopeeの商品IDです
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
Product Name: 商品名
Product Weight/kg: 重さ
Length: 長さ
Width: 横幅
Height: 高さ
Shipping Toggle: 配送切替onまたはoffを指定
I will cover shipping fee: 送料無料onまたはoffを指定
Shipping fee: 配送料
Fail Reason: 基本的に空欄

### mass_update_media_info
Product ID: Shopeeの商品IDです
Parent SKU: 該当商品の登録情報「Parent SKU」が出力されます
Product Name: 商品名
Category: カテゴリのIDと構造。例: 100893 - Beauty/Skincare/Facial Moisturize
Cover image: カバー画像のURL
Item Image 1〜8: 画像1〜8のURL
Size Chart: サイズチャート画像のURL
Variation Name1: バリエーション1の名前    
Option 1 Name〜Option 30 Name: オプション1〜30の名前
Option 1 Image〜Option 30 Image: オプション1〜30の画像URL
Fail Reason: 基本的に空欄


一括での引っ越し作業などの際参照いただければ幸いです。

Shopeeで出力できる商品CSVの種類と内容

# 軽量でセキュアなコンテナイメージを使ってみよう

## はじめに
みなさんは開発にDockerコンテナを使っていますか？ここでいうコンテナとはDockerやDocker互換のコンテナエンジンで動作させられるものを指します。
当社でもDockerコンテナを積極的に利用して開発環境から本番までシームレスな開発、運用ができるよう導入を進めています。

さてそんなDockerコンテナですが、コンテナイメージを管理するためのDockerfileは適切に管理できているでしょうか。
ファイルシステムが差分構成になっていることなどDocker特有の仕組みがあり、ネット上にあるサンプルをそのまま使っているだけで自分たちで中身を書くところまではできてない人が多いのではと想像します。

本記事ではそのような状態から一歩レベルアップするため、Distrolessというベースイメージを使うようDockerfileを書き換えるやり方とその結果どういうことが得られるかを解説していきます。

## Distrolessとは
そもそもDistrolessとはどういうもので、どういう利点があるのでしょうか？
開発元でGoogleのAIであるBardに聞いてみた内容を引用します。

> 引用：Bard（Google AI）

> 質問
> distrolessを使う利点はなんですか？
> 
> 回答
> Distroless は、Google によって開発された、Linux オペレーティングシステムを最小化した Docker コンテナイメージです。Distroless は、アプリケーションを実行するために必要な最小限のファイルとライブラリのみを含むため、軽量でセキュリティに優れています。
> 
> Distroless を使用する主な利点は次のとおりです。
> 
> - 軽量：Distroless は、従来の Linux ベースの Docker コンテナイメージよりも軽量です。これは、Distroless がアプリケーションを実行するために必要な最小限のファイルとライブラリのみを含むためです。
> - セキュリティに優れている：Distroless は、セキュリティに優れています。これは、Distroless がアプリケーションを実行するために必要な最小限のファイルとライブラリのみを含むため、攻撃対象領域が狭いためです。
> - スケーラブル：Distroless はスケーラブルです。これは、Distroless が軽量であるため、多くのコンテナを実行してもシステムに負荷がかかりにくいためです。
> 
> Distroless は、軽量でセキュリティに優れた Docker コンテナイメージを必要とするアプリケーションに最適です。たとえば、Web サーバ、データベースサーバー、アプリケーションサーバなどです。

「軽量でかつセキュリティに優れている」というところに着目してDistrolessを使って進めていきます。

## プログラム
実際の運用イメージにあわせるため、下記のようなExpressを使ったNode.jsアプリを動作させるコンテナを作るDockerfileを対象にします。

- app/app.ts
  ```
  import express from "express";

  const app = express();
  const port = 3000;

  app.get("/", (_req, res) => {
    res.send("Hello World!");
  });

  app.listen(port, () => {
    console.log(`Example app listening on port ${port}`);
  });
  ```
- package.json
  ```
  {
    "dependencies": {
      "express": "^4.18.2",
      "typescript": "^5.1.6"
    },
    "devDependencies": {
      "@types/express": "^4.17.17"
    },
    "scripts": {
      "build": "tsc"
    }
  }
  ```
- tsconfig.json
  ```
  {
    "compilerOptions": {
      "target": "es2016",
      "module": "commonjs",
      "outDir": "./dist",
      "esModuleInterop": true,
      "forceConsistentCasingInFileNames": true /* Ensure that casing is correct in imports. */,

      /* Type Checking */
      "strict": true /* Enable all strict type-checking options. */,
      // "noImplicitAny": true,                            /* Enable error reporting for expressions and declarations with an implied 'any' type. */
      // "strictNullChecks": true,                         /* When type checking, take into account 'null' and 'undefined'. */
      // "strictFunctionTypes": true,                      /* When assigning functions, check to ensure parameters and the return values are subtype-compatible. */
      // "strictBindCallApply": true,                      /* Check that the arguments for 'bind', 'call', and 'apply' methods match the original function. */
      // "strictPropertyInitialization": true,             /* Check for class properties that are declared but not set in the constructor. */
      // "noImplicitThis": true,                           /* Enable error reporting when 'this' is given the type 'any'. */
      // "useUnknownInCatchVariables": true,               /* Default catch clause variables as 'unknown' instead of 'any'. */
      // "alwaysStrict": true,                             /* Ensure 'use strict' is always emitted. */
      // "noUnusedLocals": true,                           /* Enable error reporting when local variables aren't read. */
      // "noUnusedParameters": true,                       /* Raise an error when a function parameter isn't read. */
      // "exactOptionalPropertyTypes": true,               /* Interpret optional property types as written, rather than adding 'undefined'. */
      // "noImplicitReturns": true,                        /* Enable error reporting for codepaths that do not explicitly return in a function. */
      // "noFallthroughCasesInSwitch": true,               /* Enable error reporting for fallthrough cases in switch statements. */
      // "noUncheckedIndexedAccess": true,                 /* Add 'undefined' to a type when accessed using an index. */
      // "noImplicitOverride": true,                       /* Ensure overriding members in derived classes are marked with an override modifier. */
      // "noPropertyAccessFromIndexSignature": true,       /* Enforces using indexed accessors for keys declared using an indexed type. */
      // "allowUnusedLabels": true,                        /* Disable error reporting for unused labels. */
      // "allowUnreachableCode": true,                     /* Disable error reporting for unreachable code. */

      /* Completeness */
      // "skipDefaultLibCheck": true,                      /* Skip type checking .d.ts files that are included with TypeScript. */
      "skipLibCheck": true /* Skip type checking all .d.ts files. */
    },
    "include": ["./src/**/*"]
  }
  ```

### Dockerfile(変更前)
```
FROM node:18-slim
WORKDIR /app
COPY . .
RUN npm install && npm run build

CMD [ "node", "./dist/app.js" ]
```
変更前のDockerfileは上記の通りで、公式で提供されているNode.jsのイメージをそのまま使うだけのDockerfileになります。

### Dockerfile(変更後)
```
FROM node:18-slim as builder
WORKDIR /app
COPY . .
RUN npm install && npm run build

FROM gcr.io/distroless/nodejs:18
ENV NODE_ENV production
WORKDIR /app
COPY --from=builder --chown=nonroot:nonroot /app/dist/app.js ./dist/app.js
COPY --from=builder --chown=nonroot:nonroot /app/node_modules ./node_modules
USER nonroot
CMD [ "./dist/app.js" ]
```
Distrolessを使うように書き換えたものがこちらになります。その中でも特に2点について下記で解説します。

### 変更内容のポイント
1. マルチステージビルド

    Distrolessには実行に必要な最低限のパッケージしか含まれていないため、npmコマンドどころかshell環境自体が存在しません。
    そのため、Dockerのマルチステージビルド機能を利用します。詳細な仕組みの説明は割愛しますが、Dockerfileの前半部分(1行目〜4行目)で
    標準Node.jsイメージを使ってアプリケーションをビルド(ライブラリのインストールとTypescriptのコンパイル)、
    後半部分(6行目〜12行目)でdistrolessに前半でビルドしたファイルのコピーするという2段階構成にします。
    このように変更することでnpmコマンドや、ソースファイルのようなアプリケーション実行に必要がないファイルをイメージファイルに含めないことを実現します。

2. 非root化

    Distrolessとは直接関係ないですが、Docker公式にもベストプラクティスとして書かれている非root化も一緒に行ってます。
    Distrolessイメージではrootユーザー以外にnonrootというユーザーが存在しているため、ファイルのコピー時とCMD実行前にnonrootを指定することでroot権限を持たないユーザーでプログラムを実行できるようになります。

### イメージのサイズの比較
まずはビルドしたイメージのサイズを比較してみます。

- 変更前→express-slim
- 変更後→express-distroless

となります。

```
➜ docker image ls
REPOSITORY           TAG       IMAGE ID       CREATED        SIZE
express-slim         latest    afe678706d58   37 hours ago   312MB
express-distroless   latest    6a1421f17b86   37 hours ago   207MB
```

3割程度小さくなっていることがわかります。
サイズが小さくなることでビルド後のイメージを保存する先のストレージ容量の節約や、デプロイ時間の短縮が期待できます。

### 脆弱性の数の比較
次に[Trivy](https://trivy.dev/)というコンテナイメージの脆弱性スキャナーをつかって検出される脆弱性の個数を比較してみます。

```
➜ trivy image express-slim
(省略)
Total: 51 (UNKNOWN: 0, LOW: 50, MEDIUM: 0, HIGH: 1, CRITICAL: 0)
(省略)

➜ trivy image express-distroless
(省略)
Total: 23 (UNKNOWN: 0, LOW: 11, MEDIUM: 8, HIGH: 4, CRITICAL: 0)
(省略)
```

今回は細かい内容までは追わずに単純な個数で比較しますが、脆弱性の数が半分以下になっていることがわかります
（HIGHが多いのが気になりますが・・）

## その他TIPSなど
### 開発中はSSHできないと不便
:debugタグをつけたイメージを利用することで一般的なコンテナイメージと同様にdocker runコマンドでsshログインが可能になります。

```
FROM gcr.io/distroless/nodejs:18
↓
FROM gcr.io/distroless/nodejs:18:debug
```

### 軽量なコンテナイメージとしてはAlpineのほうが有名なのになぜDistrolessを採用しているのか
Alpineは軽量にするため特殊構成をとっているディストリビューションであり、標準Cライブラリに一般的なglibcではなくmuslを採用しています。
Node.jsではmuslを採用しているプラットフォームで動作させる場合のサポートレベルはExperimentalとなっています(2023年8月現在)。
この点から、実運用時の安定性のことを考えて一般的なディストリビューションであるDebianベース(=標準Cライブラリがglibc)のDistrolessを使いました。

## まとめ
今回はNode.jsのアプリケーションを動かすコンテナをDistrolessを使って構築してみましたが、変更自体も簡単で、記事内で解説したとおり軽量かつセキュアなコンテナにするという目的が達成できそうです。

その要因として、Node.jsインストール済みのイメージがDistrolessで提供されていることが大きかったのですが、たとえばPHPのように標準で提供されてないアプリケーションのコンテナイメージを構築する場合、自前でミドルウェアを追加する作業が必要になり、軽量かつセキュアというメリットがあまり活かせないことになりそうです。

用途に応じた使い分けが必要だと感じました。

## 参考リンク
- [Distroless](https://github.com/GoogleContainerTools/distroless)
- [Best practices for writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)
- [DockerでNode.jsを動かすときのベストプラクティス](https://blog.shinonome.io/nodejs-docker/)
- [Node.js Docker baseイメージには alpine < distroless < ubuntu+slim 構成がよさそう](https://zenn.dev/jrsyo/articles/e42de409e62f5d)

20230825_1.png

軽量でセキュアなコンテナイメージを使ってみよう

## React初体験

今月にスターフィールド のWebサイトが新しくリニューアルされました。この開発に伴い始めてReact環境で開発を体験しました。
ReactはJavaScriptのライブラリの一種と聞いてはいましたが、Webデザイナーとして経験してきたJavaSciptの開発とは全く別物のように感じました。

このブログでは、React環境での開発体験を詳しくまとめて、初心者がReactに挑戦する際に直面するであろう注意点、気づいたポイントについてまとめます。


## そもそもReact とは？

ReactはJavaScriptライブラリであり、主にユーザーインターフェースを構築するのに向いています。近年、Webサイトを構築する上でheader、footerなど
共通部分をモジュール化し、それを読み込ませてページを作ります。
Reactはこのモジュール化の考え方が色濃く表れてる言語という印象を受けました。また、そのため今までの開発環境と大きく変わりました。

例えば、jQuery環境で開発する場合、一般的には<head>タグ内にjQueryファイルを読み込むコードを記載するでしょう。そして、topページ内ではメインビジュアルをslickスライダーなどのモジュールを読み込み動きを設定し、CSSで装飾をする。などの流れで動きのあるリッチコンテンツを作ります。

しかし、Webサイト全体を見た場合、例えばプライバシーポリシーページなど、ただテキストを配置するだけで、特別な仕掛けもないページも存在します。このとき、不要なページにもjQueryファイルを読み込ませてしまい、サーバーには余計な負荷を書けることになります。

一方、Reactの場合、例えばメインビジュアルのスライダーは<slider>などの名前でモジュール化します。そして、このモジュール専用のHTMLとCSSを作成してまずこの部分だけ完成させます。その後、必要なページの必要な箇所でこの<slider>を読み込みWebページを作成します。
各ページ毎に読み込むページが必要最低限で済むのでデータ通信の容量を軽くできます。

一見すると、WordPressでもよく使われる「include」により、各パーツを指定してページを構成する方法と似ていますが、大きく違うのはWordPressは呼び出すデータはHTMLだけになります。そのため呼び出したページのCSSで、読み込んだHTMLに改めてスタイルを適用させる必要があります。  
しかし、Reactの場合はCSSも適用された完成形の形でモジュールが呼び出されるため、改めてスタイルを適用させるを必要もありません。

例えるなら、ブロック工法（機械や建物の製造時に、いくつかの要素を分けて同時に製造し、最後に繋ぎ合わせて完成させる工法）に近い考え方でページを作ります。


## 実際の記述について

開発を体験してみて、記述の仕方が独特と感じました。実際に特徴的だと思った点を主にまとめてみました。

・各ページ、モジュールを「.tsx」ファイルで作る。

先ずは各ページのモジュールを作ります。

```
import Head from 'next/head';
import styles from '@/styles/career.module.scss';


function 関数() {
  return (
       実際のHTML
  );
}

```


という形で記述します。

また、HTMLの記述も全てのタグを「 /(スラッシュ)」を記述して閉じなくてはいけません。大概のタグは/(スラッシュ)で閉じるので当たり前ですが、<br>や<img>タグにもそのルールが適用されて、まるでXHTMLのような記述をする必要があります。

またCSSも

```
<div className={styles.textArea}>

```

などのような形で指定していきます。


少しでもミスがあるとエラーが出てしまい、表示が崩れてしまうレベルではなく、ページその物が閲覧できない状態となり戸惑いました。


## 外部ライブラリーやプライグインを使う場合

トップ画面などで、複数枚の画像をスライダーで見せるホームページはよくあります。jQuery環境下ではこのようなコンテンツを作る際は、主に、slickスライダーなど、有名なプラグインを使うケースが多いです。Reactでもこのようなプラグインを使うことができます。

slickスライダーを例に、React で プラグインを使う場合は以下のようにします。

先ず、

```
$ npm install react-slick

（yarn を使っている場合は yarn add react-slick ）

```

とコードを導入して、プロジェクトに　silick スライダーをインストールします。

そして、.tsvファイルにCSSと同様に

```
import Slider from 'react-slick';
import "slick-carousel/slick/slick.css";
import "slick-carousel/slick/slick-theme.css";

```

と記述します。
これで　sickスライダーが使える環境が整います。

後は他のモジュールと同様に作成していきます。
例えば、


```

function slickContents() {
  const settings = {
    dots: true,
    autoplay: true,
    infinite: true,
    speed: 500,
    slidesToShow: 1,
    slidesToScroll: 1
  }
  
  return (
    <ul>
      <Slider {...settings}>
        <li><img src={img1} alt='img1' /></li>
        <li><img src={img2} alt='img2' /></li>
        <li><img src={img3} alt='img3' /></li>
      </Slider>
    </ul>
  );
}

```

などのように記述します。

```
  const settings = {
  }

```


こちらの箇所でslickスライダーの設定をします。
jQueryでは外部ファイルのjsファイルに記述して設定するケースが多いですが、記述する位置が違うだけで設定の方法は概ね同じです。

スライダーの動きを設定したあと　

```
  return (　)

```


で実際のHTMLを書き、モジュールを作成します。

そして、実際にスライダーを掲載したい位置に

```

<slickContents/>

```


と記載する事でスライダーが設置されます。

reactは全般的にこのような流れで開発を進めていきます。



## プラグインを使わないコードについて

jQuery環境で開発をする際、プラグインを使わず自分で簡単なコードを記述してコンテンツを作る場合があります。
例えば、クリックしたらclss 「on」 を追加し、CSSで実際にその変化を作るということはよくありました。

同じ事をReact環境下でも行いました。

今回実際にアコーディオン形式でクリックしたら配下のコンテンツの表示、非表示が切り替える動きを作りました。

li="dropListItem" をクリックしたら　これにon を追加したり、削除する。という動きを作りました。
そして、CSSで　li="dropListItem on"　の時は配下の hideArea が表示されるという仕掛けを作成しました。


実際には以下のように記述しました。

```
import React, {useState} from 'react';


function DropListItem ({title , text}) {
  const [isOn, setIsOn] = useState(false);
  const handleClick = () => {
    setIsOn(!isOn);
  };

  return (
    <li className={`dropListItem ${isOn ? 'on' : ''}`} onClick={handleClick}>
      <div className={styles.showArea}>
        <p>{title}</p>
      </div>

      <div className={styles.hideArea}>
        <p>{text}</p>
      </div>
    </li>
  )
}

```

先ずはReqctの「useState」という関数を使うので先に、

```
import React, {useState} from 'react';

```
と記述します。

そして、

```
function DropListItem  ({title , text})

```
と従来の流れ通りにモジュールのタイトルを設定します。

```
{title , text}

```
の部分は最後に解説します。


今回はHTMLに　on  と off　の二段階の変化があります。このように変化するとき
useStateを使います。

```
const [isOn, setIsOn] = useState(false);

```

と、記述したのは「isON」という状態になるときと、「setIsOn」という状態になるときがある。
そして、

```
useState(false);

```

と書くことで書記状態は useState で指定する変化がない状態という意味合いになります。

```
  const handleClick = () => {
    setIsOn(!isOn);
  };

```


この関数は hadleClick という関数が呼び出される度に、「setIsOn」と「isOn」　という状態が切り替わるという意味になります。

そして、実際にHTMLを記載する際に

```
<li className={`dropListItem ${isOn ? 'on' : ''}`} onClick={handleClick}>

```


と記載しました。
解説すると、先ず、

```

className={ dropListItem } 

```


と記載し、liに「dropListItem」　というclass名を付けます。

```

${isOn ? 'on' : ''}

```


この部分の意味は　isOnの状態では、class「on」を追加、そうでないときは空白を入れる、つまり何も入れない状態にする。という意味になります。

```

onClick={handleClick}

```

はクリックした際に 「handleClick」を呼ぶという状態になります。

事前に、「handleClick」は「isOn」と「setIsOn」を切り替えるように設定しているのでクリックする度に on が挿入した状態とされない状態に切り替わるようになります。

これで、動作については完成しました。後は、実際にを配置したい場所に

```

<DropListItem />

```


と記述することで配置できます。

しかし、この<DropListItem />は配下のテキストを変えて複数配置するコンテンツです。そのため、実際に変えるテキスト部分は関数にして、各<DropListItem />ごとにテキストを変えられようにしました。

そのため、先ず、

```

function DropListItem  ({title , text})

```

と記載し、

実際にテキストを変えるHTMLには


```
    <li className={`dropListItem ${isOn ? 'on' : ''}`} onClick={handleClick}>
      <div className={styles.showArea}>
        <p>{title}</p>
      </div>

      <div className={styles.hideArea}>
        <p>{text}</p>
      </div>
    </li>

```
と記載しました。

最終的には以下のように記述します。

```

<ul>タイトル1の詳細情報を記載ます。
  <DropListItem title="タイトル1" text="タイトル1の詳細情報を記載します。"/>
  <DropListItem title="タイトル2" text="タイトル2の詳細情報を記載します。"/>
  <DropListItem title="タイトル3" text="タイトル3の詳細情報を記載します。"/>
  <DropListItem title="タイトル4" text="タイトル4の詳細情報を記載します。"/> 
</ul>

```

このような流れでアコーディオン形式のコンテンツの作成ができました。


6　まとめ

Reactは今までのHTMLとCSS、それにjQueryによる開発に慣れている人から見たら全く違う物のように感じます。そのため戸惑う部分が多くあります。
しかし、モジュール単位で開発をするという性質上、複数人での開発に適していると感じました。

せっかく会社に属して仲間と共に開発の仕事をしているので、積極的に覚えてより良い物を作りたいと思いました。








Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - カテゴリー: 開発ナレッジ

2024/04/19

2024/04/05

2024/03/15

2024/03/01

2024/02/22

2024/02/02

2024/01/19

2024/01/05

2023/12/08

2023/11/24

2023/11/10

2023/10/20

2023/10/05

2023/09/22

2023/09/08

2023/08/25

2023/08/25

2023/07/28