OmniAICreator/Qiita-1.07M huggingface dataset:
Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

# ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
PCをシャットダウンして再度立ち上げ直した時によく下記エラーが発生する。

```
$ mysql -u root
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
```

/tmp/mysql.sockがないと言われているので、ファイルを作ってみる。

```
$ sudo touch /tmp/mysql.sock
#=> パスワードを求められるので、PCのパスワードを入力する
```

## ERROR! The server quit without updating PID file (/usr/local/var/mysql/*****.pid).

その後、mysqlを再起動しようとすると次のエラーが発生する。
PIDファイルを更新せずにサーバが終了しましたというエラー内容。

```
$ sudo mysql.server restart
 ERROR! MySQL server process #8166 is not running!
Starting MySQL
. ERROR! The server quit without updating PID file (/usr/local/var/mysql/*****.pid).
```

指摘されている箇所を見にいくと、該当のファイルが存在しなかった。
調べてみると、どうやら

- (1)pidファイルが存在しない
- (2)pidファイルに適切な権限が設定されていない

ことが原因として挙げられるそうです。

現状確認

```
$ mysql --version
mysql  Ver 8.0.22 for osx10.15 on x86_64 (Homebrew)
```

### (1)PIDファイルを作成する

```
$ touch /usr/local/var/mysql/＊＊＊＊＊*.pid

# ファイル名である「*****.pid」の*****には、マシンのホスト名を入力する。
# マシンのホスト名は $ uname -n で確認可能
```

ファイルが作られたので、試しに再度下記コマンドを打つもエラーとなっている

```
$ sudo mysql.server restart
Password:
 ERROR! MySQL server PID file could not be found!
Starting MySQL
. ERROR! The server quit without updating PID file (/usr/local/var/mysql/*****.pid).
```

### (2)PIDファイルの権限を変更する

```
$ cd /usr/local/var/mysql/
$ ls
#=> さっき作ったファイルが消えている(?)
```

権限を変更する前に、一度mysqlフォルダにあるファイルの権限状態を確認しにいきました。
そうすると、さっき作ったはずのファイルがなくなっていました。
理由はわからないので、再度PIDファイルを作って確認。

```
$ touch /usr/local/var/mysql/＊＊＊＊＊*.pid
$ ls
#=>ファイルの存在を確認

# 再度mysql立ち上げを試みるもエラーが発生。
$ sudo mysql.server restart
Password:
 ERROR! MySQL server PID file could not be found!
Starting MySQL
. ERROR! The server quit without updating PID file (/usr/local/var/mysql/*****.pid).

#=> この時点で再度ファイルを確認すると、またしてもなくなっている。(???)
```


## PIDファイルを作成し、権限を変更した後、mysqlを立ち上げてみる

```
$ touch /usr/local/var/mysql/＊＊＊＊＊*.pid
$ sudo chown _mysql:_mysql /tmp

# 再起動するも、またPIDファイルがないと言われる(泣)
$ sudo mysql.server restart
 ERROR! MySQL server PID file could not be found!
Starting MySQL
. ERROR! The server quit without updating PID file (/usr/local/var/mysql/*****.pid).
```

# どうしようもないので、mysqlを再インストールする

```
$ brew uninstall mysql

# この時点でmysql.server startとしてもエラーのまま

# 一度サーバーをシャットダウンしてみる
$ sudo shutdown -r now
```

```
# 再度サーバーを起動させる
$ mysql.server start
Starting MySQL
.. SUCCESS!
```

**起動できました！！！**

なんとか起動し直すことができました。ただなぜ上手くいかなかったのかまではあまり追及できなかったので備忘録としてキーワードだけ残しておくことにします。まだエラーで詰まった場合は下記キーワードとこの備忘録を元に早急なエラー対処ができることを切に願う。

- PIDファイルは存在するか
- PIDファイルの権限はどうなっているか
- どうしようもない場合はmysqlを再インストールすること
- mysqlを立ち上げてみる前に、一度サーバーをシャットダウンする

# 参考

- [mysqlが起動できない（Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)）](https://qiita.com/carotene4035/items/e00076fe3990b9178cc0)

- [どうしよう！困った時のMac上のMySQLのアンインストール＆再インストール、動作確認手順](https://qiita.com/akiko-pusu/items/aef52b723da2cb5dc596#homebrew%E3%81%A7%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E5%86%8D%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B)

- [[2002] MySQLのソケットエラー の原因と対処法](https://beyondjapan.com/blog/2016/03/2002-mysql-socket-error/)
初投稿―自然言語とプログラミング言語のあれこれ―自己紹介を兼ねて

# Qiitaでの情報発信の目的・内容
* 自然言語とプログラミング言語の性質の違いについて述べたサイトはいくつか見つかります。例えばプログラミング言語の文法は厳格だが、自然言語は文法を間違えても通じてしまう、などです。
* が、言語獲得の過程、言語教育のありかたに関して、自然言語とプログラミング言語の違いについて述べた情報はほとんど見つからないです。
* ここでは、自分が初めてプログラミング言語に触れたときにどのような思考過程を経てできるようになっていったか、とか、自分ならプログラミング初心者にどう教えるか、などについて、自然言語との違いを踏まえつつ、普段考えていることをアウトプットしていきたいと思います。

# テンソル(私)の自己紹介
* 大手塾で、個別指導でプログラミングを教えています。(一般的な学校科目も教えています。)
* IT業界経験は15年。つい最近引退し、教育事業や文筆の仕事にシフトしつつあります。
* 最初にまともに使えるようになった言語はPerlですが、今や非メジャーな言語となってしまいましたね。Perlは大学院生のときに触りはじめ、就職後も使いました(就職当時はメジャーだったのです)。仕事では他に、PHP, HTML/CSS, JavaScript, ruby, python, シェルスクリプト, SQL, Visual Basic, Excel VBAなどを経験。引退前の直近ではNoCodeツールであるMicrosoft Power Platformの経験も。
* Scratch, C++, Java, C# について、直接の開発経験はありませんが、指導実績があります。上述の経験言語の中で指導実績がある言語は、HTML/CSS, JavaScript, python。
* 1990年代後半、大学の学部生でした。言語学を専攻。当時から語学学習がたいして苦にならず、かじってみた言語の数はたぶん今まで15～20か国語ぐらいです。英語以外の自然言語でいちばんまともに使えるのは中国語で、英語教育相当で高３～大１ぐらい。
* 2000年代の前半は大学院生でした。自然言語処理と音声認識/音声合成処理を主に研究している研究室に所属していました。現在のAI技術の源流が当時にあります。つまり、当時さかんに研究されていた機械翻訳や音声認識の技術が、成熟して一般の人の目に見られるようになりました。機械学習・データサイエンス・人工知能関連についても、(就職後に不勉強になったので勘をとり戻して)教える側にまわりたいです。
PowerShellにコピペするだけでファイルを指定行数で分割できるやつ

#何をしたいん？
1. MariaDBをレプリケーションしてる。
2. プライマリとセカンダリ間で正常にレプリケーションできてるか確認したい。
3. プライマリとセカンダリの両方からmysqldumpしたファイルをWinMergeで差分チェックしよう！
4. 1ファイルあたりの行数多すぎるとWinMergeで比較できない…(´・ω・`)

ということで、mysqldumpしたファイルを指定行数で分割したいわけどす。

#コピペで使えるスクリプト
先頭の『ファイルパス』『エンコード』『分割行数』を書き換えて、PowerShellに貼り付ければ使えるやつを作ってみました。

```powershell:
$file_path = 'ファイルパス';
$encode = 'UTF8'; #SJISなら『default』
$row_size = 100; #分割行数
$file_name = $(Get-ChildItem $file_path).BaseName;
$file_extenstion = [System.IO.Path]::GetExtension($file_path);
$parent_folder_path = Split-Path $file_path -parent;
$i = 0;
cat $file_path -ReadCount $row_size -Encoding $encode | % {
	$tmp_file_path = $parent_folder_path + '\tmp' + $i + $file_extenstion;
	$output_file_path = $parent_folder_path + '\' + $file_name + '_' + $i + $file_extenstion;
	$_ > $tmp_file_path;
	get-content -Encoding Unicode $tmp_file_path | Set-Content -Encoding $encode $output_file_path;
	Remove-Item $tmp_file_path;
	$i++;
}
```
このスクリプトのちょっとダメなとこ

* エンコードし直しの為に一時ファイルに出力してる。（tmpという名前のファイルは分割できない）
* 分割元のファイルのエンコードは『UTF8』『SJIS』のみ対象。
* 分割後のファイルと同名のファイルがあったら上書きされちゃう。

ちょっとスマートじゃないなあ…(´・ω・`)
あくまで個人用のぷちツールです。

#実行するとこんな感じ

* 分割元のファイルと同じフォルダに分割後のファイルが作成されます。
* 分割元のファイルはそのまま残ります。
* 分割元のファイル名と拡張子を引き継いでファイルを分割します。
* 分割後のファイル名には通し番号が付きます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/706116/eae484c9-25e4-2b28-16c9-8698bb59f142.png)

#何で一時ファイルに出力してからエンコードし直してるの？

1. PowerShellのデフォルトのエンコードはUTF-16。
2. 上記の為に ```$_ >``` の箇所で出力されるファイルのエンコードはUTF-16になってしまう。
3. パイプ処理の中でエンコードを指定すればいいんだろうけど、やり方分からんかった…(´・ω・`)

妥協して一時ファイル出力してます。

#蛇足
汎用性持たせたり例外処理も盛り込みたいならC#でexe作った方がいいと思います。

#バージョン
Windows10 Pro バージョン20H2 OSビルド19042.685
PSVersion 5.1.19041.610
docker-composeの--build-argオプションを利用して、Dockerfileでビルドされるコンテナまで環境変数を渡す

## 流れ

1. `--build-arg`オプションを利用して、環境変数をDocker-Composeに渡す
2. Docker-Composeでは、あらかじめ`--build-arg`に渡す予定の変数を宣言しておく
3. Docker-Composeから読み込まれるDockerFileでは、ARGで変数を呼び出し、ENVでコンテナへ埋め込む

## 実行コマンド

```bash
docker-compose build --build-arg BUILDID=4d345663-5247-465d-b522-1d3c08b5d243
```

## docker-compose
- argsで指定しておく
- この際、変数の値は上書きされるので適当でいい

```docker-compose.yaml
version: '3.7'
services:
  app:
    build:                                                                                        
      context: ./app
      dockerfile: ./Dockerfile
      args:    
        - BUILDID=test
```

## Dockerfile
- ARGで読み込む
- ENVで埋め込む

```Dockerfile
ARG BUILDID
ENV buildid=${BUILDID}
```
[日本語訳]SWR 発展 パフォーマンス

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [Performance – SWR](https://swr.vercel.app/advanced/performance)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# パフォーマンス

SWRは、あらゆる種類のWebアプリで重要な機能を提供するため、**パフォーマンス**が最優先事項です。

SWRの組み込みの**キャッシュ**と[重複排除](#重複排除)は、不要なネットワークリクエストをスキップしますが、`useSWR`フック自体のパフォーマンスは依然として重要です。 複雑なアプリでは、1ページのレンダリングで何百もの`useSWR`呼び出しが発生する可能性があります。

SWRはあなたのアプリに下記を保証します:

- 必要のないリクエストを送らない
- 必要のない再レンダリングをしない
- 必要のないコードのインポートしない

コードを変更することなく。

# 重複排除
アプリでSWRフックを再利用することは非常に一般的です。 たとえば、現在のユーザーのアバターを5回レンダリングするアプリ:

```tsx

function useUser () {
  return useSWR('/api/user', fetcher)
}

function Avatar () {
  const { data, error } = useUser()
  if (error) return <Error />
  if (!data) return <Spinner />
  return <img src={data.avatar_url} />
}

function App () {
  return <>
    <Avatar />
    <Avatar />
    <Avatar />
    <Avatar />
    <Avatar />
  </>
}
```

各`<Avatar>`コンポーネントには`useSWR`フックがあります。それらは同じSWRキーを持ち、ほぼ同時にレンダリングされるため、**一度だけネットワークリクエスト**が行われます。

パフォーマンスや重複したリクエストを心配することなく、どこでもデータフック（上記の例の`useUser`など）を再利用できます。

デフォルトの [`dedupingInterval` オプション](https://qiita.com/tk1024/items/35afe470c6f322ff5dc8)をオーバーライドするための重複排除間隔のオプションもあります。

# 深い比較
SWRは、デフォルトでデータ変更の**深い比較**をします。 `data`の値が変更されていない場合、再レンダリングはトリガーされません。

動作を変更したい場合は、[compareオプション](https://qiita.com/tk1024/items/35afe470c6f322ff5dc8)を使用して比較機能をカスタマイズすることもできます。 たとえば、APIレスポンスがサーバーのタイムスタンプを返し、データ差分から除外したい場合など。

# 依存関係の収集
`useSWR`は、`data`、`error`、`isValidating` の3つの**ステートフル**な値を返します。それぞれを個別に更新できます。 たとえば、完全なデータフェッチライフサイクル内でこれらの値を出力すると、次のようになります。

```tsx

function App () {
  const { data, error, isValidating } = useSWR('/api', fetcher)
  console.log(data, error, isValidating)
  return null
}
```

最悪のケース（最初のリクエストが失敗し、次の再試行が成功した場合）、5行のログが表示されます。

```
// console.log(data, error, isValidating)
undefined undefined false // => ハイドレーション / 初回レンダー
undefined undefined true  // => フェッチ開始
undefined Error false     // => フッチ終了、エラーを取得
undefined Error true      // => リトライ開始
Data undefined false      // => リトライ終了、データを取得
```

状態変化は理にかなっています。 しかし、それはまた、コンポーネントが**5回レンダリング**されることを意味します。

`data` のみを使用するようにコンポーネントを変更した場合:

```tsx

function App () {
  const { data } = useSWR('/api', fetcher)
  console.log(data)
  return null
}
```

魔法が起こります — 現在、再レンダリングは2回だけです。

```
// console.log(data)
undefined // => ハイドレーション / 初回レンダー
Data      // => リトライ終了、データを取得
```

まったく同じプロセスが内部で発生し、最初のリクエストはエラーが発生し、再試行からデータを取得しました。 ただし、**SWRは、コンポーネントによって使用されているステートのみを更新**します。現在は`data`のみです。

これら3つのステートすべてを常に使用しているわけではない場合は、すでにこの機能の恩恵を受けています。 <a href="https://vercel.com/">Vercel</a>では、この最適化により再レンダリングが最大60％少なくなりました。


# Tree Shaking
SWRパッケージは、<a href="https://webpack.js.org/guides/tree-shaking/">tree-shakeable</a>で副作用がありません。 つまり、コアの`useSWR` APIのみをインポートする場合、`useSWRInfinite` などの未使用のAPIはアプリケーションにバンドルされません。
[日本語訳]SWR ドキュメンテーション サスペンス

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [Suspense – SWR](https://swr.vercel.app/docs/suspense)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# サスペンス

🚨 サスペンスは現在、Reactの実験的な機能です。 これらのAPIは、Reactの一部になる前に、警告なしに大幅に変更される可能性があります。
<a href="https://reactjs.org/docs/concurrent-mode-suspense.html">詳しくはこちら</a>

💡 React SuspenseはまだSSRモードをサポートしていないので注意してください。

`suspense`オプションを有効にして、React SuspenseでSWRを使用できます。

```tsx

import { Suspense } from 'react'
import useSWR from 'swr'

function Profile () {
  const { data } = useSWR('/api/user', fetcher, { suspense: true })
  return <div>hello, {data.name}</div>
}

function App () {
  return (
    <Suspense fallback={<div>loading...</div>}>
      <Profile/>
    </Suspense>
  )
}
```

💡 `Suspense` オプションは、ライフサイクルの中で変更することができないことに注意してください。

サスペンスモードでは、`data` は常にフェッチレスポンスです（したがって、データが`undefined`かどうかを確認する必要はありません）。 ただし、エラーが発生した場合は、<a href="https://reactjs.org/docs/concurrent-mode-suspense.html#handling-errors">error boundary</a>を使用してエラーをキャッチする必要があります。


```tsx

<ErrorBoundary fallback={<h2>Could not fetch posts.</h2>}>
  <Suspense fallback={<h1>Loading posts...</h1>}>
    <Profile />
  </Suspense>
</ErrorBoundary>
```


# 備考: 条件付きフェッチと共に使用する
通常、`Susponse`を有効にすると、`data`は常にレンダリング時に準備ができていることが保証されます。

```tsx

function Profile () {
  const { data } = useSWR('/api/user', fetcher, { suspense: true })

  // `data` は `undefined` にはならない
  // ...
}
```

ただし、条件付きフェッチまたは依存フェッチと一緒に使用する場合、リクエストが**開始しない**場合に`data`は`undefined`になります。

```tsx

function Profile () {
  const { data } = useSWR(isReady ? '/api/user' : null, fetcher, { suspense: true })

  // `data` は `isReady` が false の時に `undefined` になる
  // ...
}
```

この制限に関する技術的な詳細を読みたい場合は、<a href="https://github.com/vercel/swr/pull/357#issuecomment-627089889">こちらのディスカッション</a>を確認してください。
[日本語訳]SWR ドキュメンテーション Next.jsと一緒に使用する

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [Usage with Next.js – SWR](https://swr.vercel.app/docs/with-nextjs)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# クライアントサイド データフェッチ
ページに頻繁に更新されるデータが含まれていて、データを事前にレンダリングする必要がない場合、SWRは最適であり、特別な設定は必要ありません。`useSWR` をインポートし、データを使用するコンポーネント内でフックを使用するだけです。

仕組みは次のとおりです。

- まず、データのないページをすぐに表示します。 データのロード状態を表示できます。
- 次に、クライアント側でデータをフェッチし、準備ができたら表示します。

このアプローチは、ユーザーのダッシュボードページに適しています。たとえば、 ダッシュボードはプライベートでユーザー固有のページであるため、SEOは関係なく、ページを事前にレンダリングする必要はありません。 データは頻繁に更新されるため、リクエスト時のデータフェッチが必要です。

# プリレンダリング
ページを事前にレンダリングする必要がある場合、Next.jsは次の<a href="https://nextjs.org/docs/basic-features/data-fetching">2つの形式のプリレンダリング</a>をサポートします。
**静的生成（SSG）**および**サーバーサイドレンダリング（SSR）**。

SWRと一緒にSEOのページを事前にレンダリングできます。また、キャッシュ、再検証、フォーカストラッキング、クライアントサイドでの間隔での再フェッチなどの機能もあります。

プリフェッチされたデータを初期値として`initialData`オプションに渡すことができます。 たとえば、[`getStaticProps`](https://qiita.com/tk1024/items/fcff84eef1c10be5d52b)と一緒に:

```tsx

export async function getStaticProps() {
  // `getStaticProps`　はサーバーサイドから呼び出されます
  // 従って、この `fetcher` 関数はサーバーサイドで実行されます
  const posts = await fetcher('/api/posts')
  return { props: { posts } }
}

function Posts (props) {
  // ここの `fetcher` 関数はクライアントサイドで実行されます
  const { data } = useSWR('/api/posts', fetcher, { initialData: props.posts })

  // ...
}
```

ページはまだプリレンダリングされています。 つまり、SEOに対応しており、キャッシュして非常に高速にアクセスできます。 また、ハイドレーション後はクライアントサイドのSWRが完全なる力を発揮します。 つまり、データは動的であり、時間とユーザーの操作によって更新されます。

💡 上記の例では、`fetcher` はクライアントとサーバーの両方からデータをロードするために使用されており、両方の環境をサポートする必要があります。 しかし、これは必須ではありません。 サーバーまたはクライアントからデータをロードするには、さまざまな方法を使用できます。
マイクロサービス推進に伴うBFFの必要性について振り返る 

# なぜ振り返るのか
マイクロサービスもBFF(Backend for Frontend)も最近出てきた。という話ではないです。
ただマイクロサービスの推進、もしくはこれからやる必要があるサービスというのは
まだまだたくさんあると思ってます。

何より自分が携わるサービスでまさにマイクロサービス化が進んでおり、
同時にネイティブアプリの開発も促進されている状態にあり、
BFFの導入検討が必要であるために振り返ってみることにしました。

# マイクロサービスとBFFの兼ね合いとは
モノリシックな状況において提供されるAPIは必要なリソースが集約されているケースが多いため、
API単体で見ると実はフロントエンド側の画面構成に対して、
必要なデータがすべて返却されるAPIがあったりもします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58973/64ee07fd-3451-15aa-8888-59428f799a15.png)

マイクロサービスが進んでいくと各サービスの連携がAPIベースになるのと、
ドメイン分析して分離が進むとはいえ、多くはデータが切り離されていくため、
リソース単位といったAPIが提供されていく。ということが増えていきます。
(正確にはもっと細かく層が分かれたりと、色んなケースがあると思いますが)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58973/27feaaff-c0d8-b982-4ffe-271f79486942.png)

この状況下において起きる懸念としてクライアントサイドでは
画面を構成する要素として複数のリソースが必要な場合に
今までは1つのAPIで提供されていたものがリソース単位に分離されたAPIを
クライアント側でそれぞれのAPI参照を行い処理を行う必要があるケースが生まれます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58973/76fb366b-c8bf-001d-c66f-c97063c7bee4.png)

これ自体は画面構成によっては最初の描画に必要なリソースをまず取得する。
なども可能となるため必ずしも悪いことばかりではないですが
クライアントサイドに関しては処理そのものや、利用するAPIが増えることで
それぞれのAPIの変化に対する考慮自体も増えることになります。

このフロントエンドの仕様に伴う複雑なAPI処理と疎結合な状態を担うために
Backend for Frontendの導入が求められるケースが出てくると考えております。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58973/07104b10-61cf-ff09-aff5-b65578bb9176.png)

# BFF導入のメリット
## フロントエンドのビジネスロジックを1つのシステムに集約できる
例えばiOSアプリ、Androidアプリで共通のBFFを利用するのであれば
両方のアプリで実装必要であったロジックを一箇所にまとめ、そこの改修だけに抑えることが可能になります。
また不具合対応もBFF側で巻き取れるケースも出てくるため、
ネイティブアプリのアップデートなしで問題解決できます

## アプリとAPIの疎結合な状態
マイクロサービス化していても既存のAPI仕様を大きく変更したり、
V2などのAPI提供が必要になることがあります。
この時、ネイティブアプリの場合はV1のAPI利用などをなくすために強制アップデートなどが必要となりますが、
BFFがその変更を吸収し、クライアントサイドに対しては互換性を保つようにすることが可能となります。

## ゲートウェイの集約
その名の通り。サービス単位でクライアントにAPI提供する場合、
それぞれがゲートウェイを考慮する必要がありますが
BFFがある場合はクライアントとBFF間のゲートウェイの考慮で済むと思います

## BFF側の問題でのキャッチアップ
ネイティブアプリで問題が起きる場合、そのエラーがアプリ側の実装によって起きてるのか、
APIより後ろ側で問題が起きてるのかを切り分けるのに時間がかかったり、が難しいケースがあると思います。
BFFが挟まることでアプリ→BFF間の問題か、BFF→API間の問題切り分けがしやすくなります。

# BFF導入のデメリット
## レイテンシーの増加
これはマイクロサービス化でもよく言われる問題ですが、
BFFを挟むことも当然レイテンシーは増加することになります。

## クライアント側でサーバ開発の領域が増える
これは組織の切り分け次第かもしれませんがシステムが増えるので当然そこの開発・運用は発生します。
それを行うためのスキルや人員はどうしても必要となります。
人員、組織を分離して構成したとしてもクライアント側の仕様、要件の理解や密な連携は必要となります。

## アプリ側の不具合吸収によるBFF側の保守コストの増大
設計次第ではありますが、常にクライアント側のバージョン情報、OS情報などを受け取っておくことで
柔軟にバージョン、OSに合わせた保守対応が可能となり、
アプリのアップデートを行わずに問題解決できるメリットがある。と同時に
BFF側で複雑なバージョン、OS判定処理などが増えるリスクも起きます。

## BFFの負荷考慮
BFFが負荷で落ちたり遅延が生じると、クライアント側全体も動かなくなってしまうリスクが生じます
そのため、負荷に対しては慎重に検証、考慮する必要がありますし
オートスケール、冗長化、マルチAZを考えるだけでなく、
ある程度の単位でAppなどを分ける設計。などを多く考える必要があります。

# BFFの技術選定
フロントエンド側での実装が多くなるはずなので、そことの親和性が高い言語選定が良い気がしております。
とはいえ複数APIの処理を行う上では並列処理の強さが必要であることは否めないと思います。
となるとNon-Blocking I/Oなどは意識する必要がある気がします。

また静的型付けの言語を採用することでBFFとAPI間で型の問題が綺麗になってる方が
クライアント側でより使いやすい形でAPI提供ができるのではないかと思います。

こうなってくるとGo、TypeScript辺りの採用が、自分の中ではイメージとして強くなりました。
サーバサイドKotrinも親和性が高く要件も満たしていそうなので良いのかもしれません。
コードで書くGoogleForms(自動返信・自動受付メールの方法)


####`今回すること`

**<応募フォーム(GoogleForms)>**
<img width="400"alt="sheet1" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/407730/ec6ee8a4-92f9-0637-2aae-0c3f3c4a2118.png">

**<自動返信メール>**
<img width="400"alt="sheet1" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/407730/7780027f-47f0-c7f9-0d4e-a1bb1b23570c.png">

応募フォーム（Googleフォーム）入力後に受付メールが自動送信される方法をやっていきたいと思います😁

##準備編
・GoogleForms作成
・スクリプトエディタを開く
<img width="400"alt="sheet1" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/407730/fdd3cf88-c7d9-ea7a-d4eb-a407f48db693.png">

##実践編

######`エディタ`

```javascript

function sendEmail(event){

var itemResponses = event.response.getItemResponses();

var name = itemResponses[0].getResponse();
var email = itemResponses[1].getResponse();
var session = itemResponses[2].getResponse();

var to = email; 
var subject = 'イベント申し込み確認メール';
var body = '${name}様\n\nお申し込み頂き、ありがとうございます。\n
          ${session}　で受付いたしました。'.replace('${name}',name).replace('${session}',session);
GmailApp.sendEmail(to,subject, body);

}
```

- <font color="MediumBlue">event</font> :イベント
- <font color="MediumBlue">response</font>:反応があった時
- <font color="MediumBlue">getItemResponses</font>:アイテムを取得する
- <font color="MediumBlue">itemResponses[0]</font>:googleFormの一番上の情報
- <font color="MediumBlue">getResponse</font>:取得
- <font color="MediumBlue">GmailApp.sendEmail(to,subject, body)</font>： GmailApp.sendEmail(メールの宛先,件名, 内容)
- <font color="MediumBlue">replace.('${name}',name):</font>${name}の部分をname<font color="Teal">（ itemResponses[0].getResponse() ）</font>に置き換える
- <font color="MediumBlue">\n</font>：改行

<font color="Crimson">解説：</font>
to(メールの宛先)：【email】、
subject(件名)：【イベント申し込み確認メール】、
body(内容)：【<font color="Navy">[応募フォームに入力した名前]</font>様<font color="Navy">[改行][改行]</font>お申し込み頂き、ありがとうございます。<font color="Navy">[改行][応募フォームで希望したセッション]</font>で受付いたしました。】

######`トリガー`

エディタだけだと、フォームを受け付けても自動で送信がされないのでトリガーの設定をする必要があります。
トリガーに移る前に、**『control+S』**でセーブを忘れずに！

<img width="500"alt="sheet1" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/407730/3ead1a73-6b23-9196-7f0d-dd5279bfac44.png">
※画像のように設定

##オマケ

######`応募を受け付けた時にメールで通知が来るようにする方法`
**<エディタ>**

```javascript

function getEmail(event){

var itemResponses = event.response.getItemResponses();

var email = '自分のメールアドレス@gmail.com'
var name = itemResponses[0].getResponse();
var session = itemResponses[2].getResponse();

var to = email; 
var subject = 'イベント受付ました';
var body = '${name}様からのお申し込み頂きました。\n
          【希望セッション】：${session}で受付いたしました。'.replace('${name}',name).replace('${session}',session);
GmailApp.sendEmail(to,subject, body);

}
```
**<トリガー>**
<img width="350"alt="sheet1" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/407730/2117ab33-08c6-2f77-1c84-c41b2b723d29.png">

**<受け取ったメール>**
<img width="400"alt="sheet1" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/407730/20890513-4f74-f117-4ded-fbc3dcdf9b6b.png">




****
<参考URL>
https://developers.google.com/apps-script/reference/gmail/gmail-app#sendEmail(String,String,String)

お疲れ様です:tangerine:
[日本語訳]SWR ドキュメンテーション プリフェッチ

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [Prefetching Data – SWR](https://swr.vercel.app/docs/prefetching)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# トップレベル ページデータ

SWRのデータをプリフェッチする方法はたくさんあります。 トップレベルのリクエストには、<a href="https://developer.mozilla.org/ja/docs/Web/HTML/Preloading_content">rel="preload"</a>を強くお勧めします。

```html

<link rel="preload" href="/api/data" as="fetch" crossorigin="anonymous">
```

HTMLの`<head>`内に配置するだけです。 簡単、高速、ネイティブです。

JavaScriptがダウンロードを開始する前であっても、HTMLがロードされるときにデータをプリフェッチします。 同じURLを使用するすべてのincomingフェッチリクエストは、結果を再利用します（もちろん、SWRを含みます）。

# プログラムでプリフェッチ
リソースを条件付きでプリロードしたい場合があります。 たとえば、ユーザーがリンクにカーソルを合わせているときにデータをプリロードする際です。 最も初期的な方法は、グローバル[ミューテーション](https://qiita.com/tk1024/items/6f09916c49fc83d3b763)を介してキャッシュを再フェッチして設定する関数を用意することです。

```tsx

import { mutate } from 'swr'

function prefetch () {
  mutate('/api/data', fetch('/api/data').then(res => res.json()))
  // 2つ目のパラメータはPromise
  // SWRは返ってきた時に結果を使います
}
```

Next.jsでの<a href="https://nextjs.org/docs/api-reference/next/router#routerprefetch">ページのプリフェッチ</a>などの手法と組み合わせることで、次のページとデータの両方を即座に読み込むことができます。
Pythonでクラスの引数や戻り値の型アノテーションに自己のクラスを指定する

## 型アノテーションに自己のクラスを指定できない

```Python:list_node.py
class ListNode:
    def __init__(self, val: int, next: ListNode):
        self.val = val
        self.next = next
```

例えば、上記（片方向連結リストのコンストラクタ）のように型アノテーションを書くと、ListNodeが定義されていないと警告が表示される。

> undefined name 'ListNode'

## Python3.7以上の場合: `from __future__ import annotations`を使用する

```Python:list_node.py
from __future__ import annotations


class ListNode:
    def __init__(self, val: int, next: ListNode):
        self.val = val
        self.next = next

assert ListNode.add.__annotations__ == {
    'next': 'ListNode'
}
```

## Python3.7未満の場合: 文字列を使用する

Python3.7未満では`from __future__ import annotations`を使用できないため、文字列を使用する。

```Python:list_node.py
class ListNode:
    def __init__(self, val: int, next: 'ListNode'):
        self.val = val
        self.next = next
```

## 参考

- [The problem of forward declarations | PEP 484 -- Type Hints | Python.org](https://www.python.org/dev/peps/pep-0484/#the-problem-of-forward-declarations)
- [前方参照の問題 - [翻訳] PEP 0484 -- 型ヒント (Type Hints) - Qiita](https://qiita.com/t2y/items/f95f6efe163b29be59af#%E5%89%8D%E6%96%B9%E5%8F%82%E7%85%A7%E3%81%AE%E5%95%8F%E9%A1%8C)
- [python - How do I type hint a method with the type of the enclosing class? - Stack Overflow](https://stackoverflow.com/questions/33533148)
- [Self-reference or forward-reference of type annotations in Python - Stack Overflow](https://stackoverflow.com/questions/36193540)
- [Python - pythonの型ヒントで自作クラスを指定したい｜teratail](https://teratail.com/questions/171609)
シェルスクリプト内で読み込まれるJSONに環境変数を渡す方法

## やり方
- `''`で囲う
- 次のシェルでは、JSONデータが次の3つのブロックに別れることになり、環境変数を読み込ませている箇所`"'${1}'"`のみ展開されるようになる
- たぶんメンテナンスするのは大変

## 例

```code-build.sh
#!/bin/bash

aws codebuild start-build \
  --project-name test \
  --environment-variables-override '[
    {
      "name": "API_HOST",
      "value": "'${1}'",
      "type": "PLAINTEXT"
    },
    {
      "name": "IMAGE_TAG",
      "value": "0.9.1",
      "type": "PLAINTEXT"
    }
  ]'    
```

```
sh code-build.sh vamdemic
```
ConfigMapを使って環境変数をPodに伝える

# ConfigMap
- 環境変数、コマンドライン引数、ボリュームを共通設定としてPodに渡すことができる
    - 各Podのマニュフェストファイルのグローバル設定的なもの
- 環境固有の設定はConfigMapに書くことで、Podなどをデプロイするマニュフェストファイルは共通のもので管理できるようになる
    - 開発環境、本番環境でFQDNが異なったりするのでそれらはConfigMapに書くと良い

# ファイルとして渡してマウントさせる場合

## configmap

### マニュフェストファイル

```config.yaml
apiVersion: v1
data:
  params.txt: |-
    name hoge
    version 1
kind: ConfigMap
metadata:
  name: params
```

### Apply

```
kubectl apply -f config.yaml
```

## configmapを読み取るpodを作成

### マニュフェストファイル

```config-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: config-test
spec:
  containers:
  - name: config-test
    image: nginx:alpine
    env:
    - name: master
      value: "true"
    volumeMounts:
    - mountPath: /mount
      name: config
  volumes:
  - name: config
    configMap:
      name: params
```

### Apply
```
kubectl apply -f config-test.yaml
```

### 確認

#### Podの起動

```
yuta:~ $ kubectl get pod config-test 
NAME          READY   STATUS    RESTARTS   AGE
config-test   1/1     Running   0          51s
```

#### Podのシェルにログイン

```
kubectl exec -it config-test /bin/sh
```

#### ファイルがマウントされていることを確認

```
/ # cat mount/params.txt 
name hoge
version 1/ # 
```

# 環境変数として渡す場合

## Configmap

### マニュフェストファイル

```env-config.yaml
apiVersion: v1
data:
  test.name: hoge
  test.version: two
kind: ConfigMap
metadata:
  name: env-params
```

### apply
```
kubectl apply -f env-config.yaml
```


## Pod

### マニュフェストファイル

```
apiVersion: v1
kind: Pod
metadata:
  name: config-env-test
spec:
  containers:
  - name: config-env-test
    image: nginx:alpine
    env:
    - name: test-name
      valueFrom:
        configMapKeyRef:
          name: env-params
          key: test.name
    - name: test-version
      valueFrom:
        configMapKeyRef:
          name: env-params
          key: test.version
```

### apply 
```
kubectl apply -f config-env-test.yaml 
```

### 動作確認

#### Podの起動
```
yuta:~ $ kubectl get pod config-env-test 
NAME              READY   STATUS    RESTARTS   AGE
config-env-test   1/1     Running   0          6m18s
```

### Podのシェルにログイン

```
kubectl exec -it config-env-test /bin/sh
```

### 環境変数がConfigMapからわたっている

```
/ # env | grep test-
test-version=two
test-name=hoge
```
※学習用メモ デザインパターン:Singleton編[PHP]

# Singletonパターンとはどういうものか

Singletonとは**一つのもの**という意味です。

>Singleton パターンとは、そのクラスのインスタンスが1つしか生成されないことを保証するデザインパターンのことである。(wikipediaより)

ポイントとしては、**指定したクラスのインスタンスが1つしか存在しないことを保証する**ということです。

インスタンスの状態を保持したかったり、クラス間で共通のメソッド・プロパティにアクセスしたい場合に使用されることが多いです。

# Singletonパターンを用いるメリット

・同一インスタンスを使いまわすので、インスタンスの状態を保持したまま他の箇所で使用できる

[参考]
https://ja.wikipedia.org/wiki/Singleton_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
https://qiita.com/shoheiyokoyama/items/c16fd547a77773c0ccc1
https://www.techscore.com/tech/DesignPattern/Singleton.html/
https://qiita.com/buntafujikawa/items/2e8e8f13b6eb2f2f9e64

# サンプルコード

## 仕様

・数字のカウントを行います。

```countData.class.php
class countData
{
    private static $_INSTANCE = NULL;
    private $countNum = 0;

    private function __construct(){}

    public static function getInstance()
    {
        if (!self::$_INSTANCE) {
            self::$_INSTANCE = new self();
        }

        return self::$_INSTANCE;
    }

    public function getCount()
    {
        return $this->countNum;
    }

    public function countUp()
    {
        $this->countNum++;
    }
}
```

## 使ってみる

```php
$instance = countData::getInstance();
print_r("初期\n");
print_r($instance->getCount() . "\n");

$instance->countUp();
print_r("カウントアップ\n");
print_r($instance->getCount() . "\n");

$sub = countData::getInstance();
print_r("取得しなおし\n");
print_r($instance->getCount() . "\n");

/*結果
初期
0
カウントアップ
1
取得しなおし
1
*/
```

上記のように、カウントアップされた後に別変数にインスタンスを再取得した場合にも、状態を保持していることが確認できます。

# まとめ

・Singletonパターンは、一つのインスタンスしか生成されないことを保証することで1つの処理の中で何回取得されても同じインスタンスを参照しで処理を進められる点が大きなメリットになります。
・例えば複数人でのゲームの場合、共通のデータを参照したい際はこのパターンを使用することで複数人の処理を同一インスタンスに対し行うことができ、何度も生成→保存の流れを繰り返すことなく処理を進めることができます。
社内SEの1年半アップデート ~やればできる~

## 職歴アップデート
**1年半前**
大手SIer　→　ブラック　→　ブラック　→　ヤクザブラック　→　グレーだけど潰れそう

**今**
大手SIer　→　ブラック　→　ブラック　→　ヤクザブラック　→　たぶん潰れました　→　まさかの中小ホワイト

なんか提案がどんどん通って、ほんとに楽しい★
## 役職アップデート
**1年半前**
主任　→　平　→　平　→　係長　→　部長　→　本部長　→　平　→　部長

**今**
主任　→　平　→　平　→　係長　→　部長　→　本部長　→　平　→　部長　→　平　→　課長代理　→　課長(予定)

役職もようやくまともなところに落ち着いた感あり。
## スキルセットの追加アップデート
【フロントサイド】
React hooks
Material UI

【サーバーサイド】
Python(Flask)
Python(バッチ処理)

まさかのモダンな作り方(自称)で業務アプリを作れるようになりました。
エクセルマクロで今まで組んでたものもPythonで組む始末。もうVBAには戻れない・・・
そしてこれからはアプリ開発に手を出しちゃう。
まさかのFlutter使います。2018年にできた最新のやつだ！！！

## 目標のアップデート
モダンな技術を使って、Webサービスをちゃちゃっと作れるような力をつける
・RailsでまずWebサービス作る
→作った
・サーバーサイド、クライアントサイドで分離した感じでWebサービス作る
　サーバーサイドはRailsのAPI、クライアントサイドはVue.js、AndroidアプリだとKotlin,IOSだとSwift
→ちょっと使った技術違うけど、クライアントサイドとサーバーサイド分離して実装できた。
・調子に乗ってきたらサーバーサイドをGoにしたり。indexDBだっけ？クライアントサイドでDBもてるやつ。を駆使したり。
上記ができるようになれば、一歩前進するかな？してくれ。
→サーバーサイドは当面Pythonで固定して、クライアントサイドを拡張していく。webはReactでいけそうなので、
あとはアプリをFlutterで実装できるかどうか

## アップデートのきっかけ
私のきっかけは「たぶん潰れました会社」にいた頃、
未踏スーパークリエータと呼ばれる人物と出会ったことです。その方から衝撃の一言。
「技術レベル低いね。今はクライアントサイドとサーバーサイド分けて、SPAで実装するのが当たり前なんだよ」
「何SPAって？食べれるの？」
「・・・」
実質初めてのWEBサービスをRailsで組んで、大満足していた私をあっさり突き落とした言葉でした。
よく調べたらRailsも時代遅れになりつつあるみたいということに気づく。
ようやく世間に追いついたと思ったら、まったく追いついてなかった事実。
何をすれば追いつくのか。。。　Reactだ！

## React導入を5回くらい諦めかけた
けど、何かのシステムを実装するとき、迷ったら難しい道を進むと勝手に決めていたので、腹据えてやりました。
それを許す会社の環境にもほんと感謝しています。ほんと何回も挫折しかけました。
来る日も来る日もReactのこと考えてました。スマホでもyahoo見ずにReact関連の検索をするという
壊れっぷり。
心の中の私が「Rails」でやれば一週間でできると囁いていましたが、我慢し続けました。

## 上達のきっかけ
Reacthooksの使い方がなんとなくわかるようになったころから、実装が楽しくなってきました。
データの受け渡し、保存、Axios実装あたりができれば、簡単な業務アプリはできることが分かりました。
CRUDの実装すら大変（特にU）でしたが、社内向け業務アプリは複雑なことは要求されないので、
CRUD＋αができれば十分なのです。この頃から、英語のすたっくおーばーふろーを見るのにも慣れてきました。
このレベルであれば、同じような悩みを投稿している人が世界に必ずいます。google検索万歳。

## やればできる！やる気の問題。+会社の環境
やればできる！外注の業者に見積500万って見積られたシステムも、自分でなんとか作れる！
てか、自分で作ったほうが早いって思えちゃう。
そうすると交渉力がまた格段に増します。諦めなければ年齢問わず技術のアップデートはできると
確信しました。そして会社の環境にも恵まれました。自分のやりたい方向を周囲が理解してくれました。
（もちろん単純に待ってもらったわけではなく、ヒアリングかけたり、サーバー整備したり、
テレワークの環境作ったりしてかわしながらやってました）
前回投稿から1年半空きましたが、また時間があれば役に立つ情報を発信したいと思います。たぶん。

## あの時の未踏スーパークリエータ様へ
少しは上達したでしょうか・・・

## たくさんのLGTM頂きました！
ありがとうございます。共感頂いている人が多数いることはとても嬉しく思います。どっかの転職記事で社内SEがシステムエンジニアのキャリアチェンジ先とかほざいているのがありましたが、なめんなと。社内SEが外注をただコントロールするだけの人だと思ったら大間違い。通常業務こなしつつ、システム作りつつ、パソコンサポートしつつ、外注先コントロールしつつ、コスト管理するとってもやりがいがあって、若干大変な仕事だかんな！
[日本語訳]SWR ドキュメンテーション 引数

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [Arguments – SWR](https://swr.vercel.app/docs/arguments)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# 引数
デフォルトでは、`key` は引数として `fetcher` に渡されます。 したがって、次の3つの式は同等です。

```tsx

useSWR('/api/user', () => fetcher('/api/user'))
useSWR('/api/user', url => fetcher(url))
useSWR('/api/user', fetcher)
```

# 複数の引数
一部の場合では、複数の引数（任意の値またはオブジェクト）を `fetcher` 関数に渡すと便利です。 たとえば、認証付きフェッチリクエスト：

```tsx

useSWR('/api/user', url => fetchWithToken(url, token))
```


これは**正しくありません**。 データの識別子（またはキャッシュキー）は `'/api/user'` であるため、`token`が変更されても、SWRは同じキーを使用し、間違ったデータを返します。

代わりに、`fetcher` の複数の引数を含む**配列**を `key` パラメーターとして使用できます。

```tsx

const { data: user } = useSWR(['/api/user', token], fetchWithToken)
```

`fetchWithToken` 関数は引き続き同じ2つの引数を受け入れますが、キャッシュキーも `token` に関連付けられるようになります。

# オブジェクトの受け渡し
ユーザースコープでデータをフェッチする別の関数 `fetchWithUser(api、user)` があるとします。 次のことができます。

```tsx

const { data: user } = useSWR(['/api/user', token], fetchWithToken)
// ...それを引数として別のクエリに渡します
const { data: orders } = useSWR(user ? ['/api/orders', user] : null, fetchWithUser)
```

リクエストのキーは、両方の値の組み合わせになりました。 SWRは、すべてのレンダリングで引数を**浅く**比較し、引数のいずれかが変更された場合は再検証をトリガーします。
オブジェクトはレンダリングごとに異なるオブジェクトとして扱われるため、レンダリング時にオブジェクトを再作成しないでください。

```tsx

// このようにしないで! 毎回のレンダーでオブジェクトが変化します。
useSWR(['/api/user', { id }], query)
// 代わりに、“ステーブル”な値だけ渡してください
useSWR(['/api/user', id], (url, id) => query(url, { id }))
```

Dan Abramovは、<a href="https://overreacted.io/a-complete-guide-to-useeffect/#but-i-cant-put-this-function-inside-an-effect">このブログ投稿</a>で依存関係について非常によく説明しています。
[日本語訳]SWR ドキュメンテーション 条件付きのデータフェッチ

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [Conditional Fetching – SWR](https://swr.vercel.app/docs/conditional-fetching)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# 条件
`null` を使用するか、`key` としての関数を渡して、条件付きのデータフェッチをします。関数がスローするか、 falsy な値を返す場合、SWRはリクエストを開始しません。

```tsx

// 条件付きフェッチ
const { data } = useSWR(shouldFetch ? '/api/data' : null, fetcher)

// ...または falsy な値を返す
const { data } = useSWR(() => shouldFetch ? '/api/data' : null, fetcher)

// ...または user.id が定義されていないのでエラーをスローする
const { data } = useSWR(() => '/api/data?uid=' + user.id, fetcher)
```

# 依存
SWRを使用すると、他のデータに依存するデータをフェッチすることもできます。 これにより、可能な限り最大の並列処理（ウォーターフォールを回避）と、次のデータフェッチ実行に必要なダイナミックデータの連続したフェッチが保証されます。

```tsx

function MyProjects () {
  const { data: user } = useSWR('/api/user')
  const { data: projects } = useSWR(() => '/api/projects?uid=' + user.id)
  // 関数を渡すとき、SWRは戻り値を `key`として使用します。
  // 関数が falsy な値か(エラーの)スローを返す場合、SWRは一部の依存関係の準備ができていないことを認識します。
  // このケースでは、`user` が読み込みされていないときに `user.id` はエラーをスローします。

  if (!projects) return 'loading...'
  return 'You have ' + projects.length + ' projects'
}
```
[日本語訳]SWR ドキュメンテーション 自動再検証

このページは [Automatic Revalidation – SWR](https://swr.vercel.app/docs/revalidation)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# 自動再検証
💡 データを手動で再検証する場合は、[ミューテーション](https://qiita.com/tk1024/items/6f09916c49fc83d3b763)を確認してください。


# フォーカスでの再検証
ページに再度フォーカスを合わせるか、タブを切り替えると、SWRは自動的にデータを再検証します。

これは、最新の状態にすぐに同期するのに役立ちます。 これは、古いモバイルタブや、**スリープ状態**になったラップトップなどのシナリオでデータを更新する場合に役立ちます。

[動画: 本家ドキュメントでご覧ください](https://swr.vercel.app/docs/revalidation)
ビデオ：フォーカスの再検証を使用して、ページ間でログイン状態を自動的に同期します。

この機能はデフォルトで有効になっています。 [`revalidateOnFocus`](https://qiita.com/tk1024/items/35afe470c6f322ff5dc8)オプションを使用して無効にすることができます。

# 時間間隔での再検証
多くの場合、複数のデバイス、複数のユーザー、複数のタブからデータが変更されます。 画面上のデータを時間の経過とともに更新するにはどうすればよいでしょうか？

SWRには、データを自動的に再フェッチするオプションがあります。 これは**スマート**です。つまり、hook に関連するコンポーネントが**画面に表示されている**場合にのみ、再フェッチが行われます。

[動画: 本家ドキュメントでご覧ください](https://swr.vercel.app/docs/revalidation)
ビデオ：ユーザーが変更を加えると、両方のセッションが最終的に同じデータをレンダリングします。

[`refreshInterval`](https://qiita.com/tk1024/items/35afe470c6f322ff5dc8)の値を設定することで有効にできます。

```tsx

useSWR('/api/todos', fetcher, { refreshInterval: 1000 })
```

`refreshWhenHidden` や `refreshWhenOffline` などのオプションもあります。 両方ともデフォルトで無効になっているため、Webページが画面に表示されていない場合、またはネットワーク接続がない場合、SWRはフェッチしません。

# 再接続での再検証
ユーザーがオンラインに戻ったときに再検証するにも役立ちます。よくあるシナリオはユーザーがコンピューターのロックを解除したときにインターネットにはまだ接続されていない場合です。

データが常に最新であることを確認するために、SWRはネットワークが回復したときに自動的に再検証します。

この機能はデフォルトで有効になっています。[`revalidateOnReconnect`](https://qiita.com/tk1024/items/35afe470c6f322ff5dc8) オプションを使用して無効にすることができます。
[日本語訳]SWR ドキュメンテーション エラーハンドリング

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください


このページは [Error Handling – SWR](https://swr.vercel.app/docs/error-handling)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# エラーハンドリング

[`fetcher`](https://qiita.com/tk1024/items/fcff84eef1c10be5d52b) 内でエラーがスローされた場合、フックによって`error`として返されます。


```tsx

const fetcher = url => fetch(url).then(r => r.json())

// ...
const { data, error } = useSWR('/api/user', fetcher)
```

fetch promise が reject された場合に`error`オブジェクトが定義されます。

# ステータスコードとエラーオブジェクト

APIがステータスコードと一緒にエラーオブジェクトを返すようにしたい場合があります。 どちらもクライアントにとって便利です。

`fetcher` をカスタマイズして、より多くの情報を返すことができます。 ステータスコードが`2xx`でない場合、JSONとして解析できる場合でも、エラーと見なされます。

```tsx

const fetcher = async url => {
  const res = await fetch(url)

  // ステータスコードの値が200-299の間でなかった場合
  // その場合でもパースを試して、スローします
  if (!res.ok) {
    const error = new Error('An error occurred while fetching the data.')
    // エラーオブジェクトに追加の情報を付け足します
    error.info = await res.json()
    error.status = res.status
    throw error
  }

  return res.json()
}

// ...
const { data, error } = useSWR('/api/user', fetcher)
// error.info === {
//   message: "You are not authorized to access this resource.",
//   documentation_url: "..."
// }
// error.status === 403
```

💡 `data`と`error`が同時に存在する可能性があることに注意してください。 そのため、UIは次のリクエストが失敗したことを認識しながら、既存のデータを表示できます。

<a href="https://swr.vercel.app/examples/error-handling">ここ</a>に例があります

# エラーでの再試行

SWRは、<a href="https://en.wikipedia.org/wiki/Exponential_backoff">指数バックオフアルゴリズム(exponential backoff algorithm)</a>を使用して、エラー時に要求を再試行します。 このアルゴリズムにより、アプリはエラーからすばやく回復できますが、リソースを無駄に再試行することはありません。

[onErrorRetry](https://qiita.com/tk1024/items/35afe470c6f322ff5dc8)オプションを使用して、この動作をオーバーライドすることもできます。

```tsx

useSWR('/api/user', fetcher, {
  onErrorRetry: (error, key, config, revalidate, { retryCount }) => {
    // 404はリトライしません
    if (error.status === 404) return

    //　特定のキーはリトライしません
    if (key === '/api/user') return

    // 10回だけリトライします
    if (retryCount >= 10) return

    // 5秒後にリトライします
    setTimeout(() => revalidate({ retryCount: retryCount + 1 }), 5000)
  }
})
```

このコールバックにより、さまざまな条件に基づいて再試行できる柔軟性が得られます。 `shouldRetryOnError：false` を設定して無効にすることもできます。

これらは [グローバル設定](https://qiita.com/tk1024/items/3e4556db98d3bd410826) Context を介して設定することもできます。

# グローバルエラーレポート
コンポーネント内の `error` オブジェクトはいつでもリアクティブに取得できます。 ただし、エラーをグローバルで処理する場合、<a href="https://vercel.com/design/toast">toast</a> や <a href="https://material.io/components/snackbars">snackbar</a> を表示するようにUIに通知する場合、または<a href="https://sentry.io/welcome/">Sentry</a>などの場所で報告する場合は、`onError`イベントがあります。

```tsx

<SWRConfig value={{
  onError: (error, key) => {
    if (error.status !== 403 && error.status !== 404) {
      // Sentry にエラーを送信します
      // または、通知UIを表示します
    }
  }
}}>
  <MyApp />
</SWRConfig>
[日本語訳]SWR ドキュメンテーション データフェッチ

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [Data Fetching - SWR](https://swr.vercel.app/docs/data-fetching)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# データフェッチ

```tsx
{ data, error } = useSWR(key, fetcher)
```

これはSWRの非常に基本的なAPIです。 ここでの `fetcher` は、SWRの**キーを受け取り**、データを返す非同期関数です。

戻り値は`data`として渡され、スローされた場合は`error`としてキャッチされます。

💡 備考: `fetcher` が[グローバル設定](https://qiita.com/tk1024/items/3e4556db98d3bd410826)から提供されている場合は、パラメーターから省略できます

# Fetch
任意のライブラリを使用して、データのフェッチを処理できます。たとえば、`fetch` ポリフィルの <a href="https://github.com/developit/unfetch">developit/unfetch</a>:

```tsx

import fetch from 'unfetch'

const fetcher = url => fetch(url).then(r => r.json())

function App () {
  const { data, error } = useSWR('/api/data', fetcher)
  // ...
}
```

💡 もし**Next.js**を使用している場合はこのポリフィルをimportする必要はありません: <a href="https://nextjs.org/blog/next-9-1-7#new-built-in-polyfills-fetch-url-and-objectassign">New Built-In Polyfills: fetch(), URL, and Object.assign</a>

# Axios

```tsx
import axios from 'axios'

const fetcher = url => axios.get(url).then(res => res.data)

function App () {
  const { data, error } = useSWR('/api/data', fetcher)
  // ...
}
```

# GraphQL

また、GraphQLと<a href="https://github.com/prisma-labs/graphql-request">graphql-request</a>のようなライブラリを使用する場合:

```tsx

import { request } from 'graphql-request'

const fetcher = query => request('/api/graphql', query)

function App () {
  const { data, error } = useSWR(
    `{
      Movie(title: "Inception") {
        releaseDate
        actors {
          name
        }
      }
    }`,
    fetcher
  )
  // ...
}
```

*GraphQLクエリに変数を渡したい場合は、[複数の引数](https://qiita.com/tk1024/items/66df360cbb1b7a7baf77)を確認してください。*
[日本語訳]SWR ドキュメンテーション グローバル設定

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [Global Configuration – SWR](https://swr.vercel.app/docs/global-configuration)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# グローバル設定

`SWRConfig` コンテキスト は全ての SWR hooks にグローバル設定([オプション](https://qiita.com/tk1024/items/35afe470c6f322ff5dc8))を提供できます。

```tsx

<SWRConfig value={options}>
  <Component/>
</SWRConfig>
```

この例では、すべての SWR hooks が提供されている同じ fetcher を使用してJSONデータを読み込み、デフォルトで3秒ごとに更新します。

```tsx

import useSWR, { SWRConfig } from 'swr'

function Dashboard () {
  const { data: events } = useSWR('/api/events')
  const { data: projects } = useSWR('/api/projects')
  const { data: user } = useSWR('/api/user', { refreshInterval: 0 }) // 上書き
  // ...
}

function App () {
  return (
    <SWRConfig 
      value={{
        refreshInterval: 3000,
        fetcher: (resource, init) => fetch(resource, init).then(res => res.json())
      }}
    >
      <Dashboard />
    </SWRConfig>
  )
}
```
[日本語訳]SWR ドキュメンテーション オプション

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [API Options – SWR](https://swr.vercel.app/docs/options)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# APIオプション

```ts

const { data, error, isValidating, mutate } = useSWR(key, fetcher, options)
```


# パラメータ
- `key`: リクエストのためのユニークな文字列キー (または function / array / null) ([高度な利用法](https://qiita.com/tk1024/items/83522a4d5743cd686df0))
- `fetcher`: (オプショナル) データをフェッチするためのPromiseを返す関数 ([詳細](https://qiita.com/tk1024/items/fcff84eef1c10be5d52b))
- `options`: (オプショナル) SWR hook オプション のためのオブジェクト

# 戻り値

- `data`: 指定されたキーに基づき、`fetcher` によって取得(解決)されたデータ (または 読み込まれていなければ undefined)
- `error`: `fetcher` によって生成されたエラー (または undefined)
- `isValidating`: リクエストがある場合 または 再検証(revalidation)の読み込み
- `mutate(data?, shouldRevalidate?)`: キャッシュされたデータを変更(mutate)する関数

# Options

- `suspense = false`: React Suspenseモードの有効化 ([詳細](https://qiita.com/tk1024/items/d1ee34b70c0ec3a180ae))
- `fetcher = window.fetch(url).then(res => res.json())`: フェッチャー関数
- `initialData`: 初回に返されるデータ (注意: フックごと) ([詳細](https://qiita.com/tk1024/items/5a7c0171fb0f09c43f13))
- `revalidateOnMount`: コンポーネントのマウント時に自動で再検証します (デフォルトでは、initialDataが設定されていない場合、マウント時に再検証が行われます。このフラグを使用して動作を強制します)
- `revalidateOnFocus = true`: windowにフォーカス時、自動で再検証します ([詳細](https://qiita.com/tk1024/items/b045b05aca74277089db))
- `revalidateOnReconnect = true`: ブラウザのネットワーク接続が回復した時に自動で再検証します(`navigator.onLine` 経由) ([詳細](https://qiita.com/tk1024/items/b045b05aca74277089db))
- `refreshInterval = 0`: ポーリング間隔 (デフォルトでは無効) ([詳細](https://qiita.com/tk1024/items/b045b05aca74277089db))
- `refreshWhenHidden = false`: ウィンドウが非表示の場合のポーリング (`refreshInterval` が有効の場合)
- `refreshWhenOffline = false`: ブラウザがオフラインの時にポーリング (`navigator.onLine` 経由で決定)
- `shouldRetryOnError = true`: `fetcher` エラー時のリトライ
- `dedupingInterval = 2000`: 指定期間中に同じキーの場合は重複リクエストを排除します
- `focusThrottleInterval = 5000`: 指定期間中に一度だけ再検証します
- `loadingTimeout = 3000`: onLoadingSlowイベントを発行するためのタイムアウト
- `errorRetryInterval = 5000`: エラーリトライの間隔
- `errorRetryCount`: エラーリトライの最大試行回数
- `onLoadingSlow(key, config)`: リクエストの読み込みに時間がかかりすぎる場合のコールバック関数 (`loadingTimeout` を参照)
- `onSuccess(data, key, config)`: リクエストが正常に終了したときのコールバック関数
- `onError(err, key, config)`: リクエストがエラーを返したときのコールバック関数
- `onErrorRetry(err, key, config, revalidate, revalidateOps)`: エラー再試行のハンドラー
- `compare(a, b)`: 誤った再レンダリングを回避するために、返されたデータがいつ変更されたかを検出するために使用される比較関数。 デフォルトでは、<a href="https://github.com/lukeed/dequal">dequal</a>が使用されます。
- `isPaused()`: 関数は再検証を一時停止するかどうかを検出し、`true` を返した場合はフェッチされたデータやエラーを無視します。デフォルトでは `false` を返します。
[日本語訳]SWR はじめに

## 追記: 2021年6月8日
[SWR公式日本語訳ページ](https://swr.vercel.app/ja)が追加されたので、そちらをご覧ください

このページは [SWR – SWR](https://swr.vercel.app/)の日本語訳です
SWR日本語訳全体については[SWR 日本語訳](https://qiita.com/tk1024/items/1b8b4eb7cfaa92be6f1a)をご覧ください

# SWR
- データフェッチのための React Hooks ライブラリ
- 軽量
- バックエンド非依存
- リアルタイム
- Jamstack 志向
- TypeScript 対応
- Remote + Local

「SWR」という名前は、<a href="https://tools.ietf.org/html/rfc5861">HTTP RFC 5861</a>で普及しているHTTPキャッシュ無効化戦略である`stale-while-revalidate`に由来します。SWRは、最初にキャッシュからデータを返し（stale）、次にフェッチリクエストを送信（revalidate）し、 最後に、最新のデータが返ります。

✅ SWRを使用すると、コンポーネントはデータ更新のストリームを**継続的**かつ**自動的**に取得します。
また、UIは常に**高速**で**リアクティブ**です。

# 概要

```react

import useSWR from 'swr'

function Profile() {
  const { data, error } = useSWR('/api/user', fetcher)

  if (error) return <div>failed to load</div>
  if (!data) return <div>loading...</div>
  return <div>hello {data.name}!</div>
}
```

この例では、`useSWR` hook は`key`文字列と`fetcher`関数を受け入れます。`key`はデータの一意な識別子（通常はAPIのURL）であり、`fetcher`に渡されます。 `fetcher`は、データを返す任意の非同期関数にすることができ、ネイティブフェッチまたはAxiosなどのツールを使用できます。

Hook は、リクエストのステータスに基づいて、`data`と`error`の2つの値を返します。

# 特徴

たった1行のコードで、プロジェクトでのデータフェッチのロジックを簡素化でき、これらすべての驚くべき機能をすぐに使用できます。

- **Jamstack**指向
- **高速**、**軽量**、**再利用可能**なデータフェッチ
- 組み込みの**キャッシュ**とリクエストの重複排除
- **リアルタイム**体験
- トランスポート・プロトコル非依存
- TypeScript 対応
- React Native

SWRは、速度、正確性、安定性のすべての側面をカバーして、より良い体験を構築するのに役立ちます。

- 高速なページナビゲーション
- ポーリング
- データの依存関係
- フォーカスでの再検証
- ネットワーク回復での再検証
- ローカルミューテーション（Optimistic UI）
- スマートなエラーの再試行
- ページネーションとスクロール位置の回復
- React Suspense
- ...

### 訳者追記
参考記事: ※ <a href="https://www.zu-min.com/archives/356">Optimistic UI とは</a>


# コミュニティ

SWRは、Reactフレームワークである<a href="https://nextjs.org/">Next.js</a>と同じチームによって作成されます。
今後のプロジェクトの更新については、Twitterで<a href="https://twitter.com/vercel">@vercel</a>をフォローしてください。

<a href="https://github.com/vercel/swr/discussions">GitHubのディスカッション</a>に気軽に参加してください！
RubyでAmazon Textractを使ってみよう

Amazon Textractを使ってみたい方のために、なんとなく実行できるコードを紹介します。

あまり世の中にAmazon Textractを利用したRubyのサンプルコードがなかったので書いてみました。
有用なコードではありませんが、RubyでAmazon Textractをとりあえず利用してみたい方には参考にしていただけるのではないかと思います。

## 諸注意

- Amazon Textractは[有料のサービス](https://aws.amazon.com/jp/textract/pricing/)です。ちょっと触ってみるだけなら無料枠でおさまるとは思いますが、実行しすぎにはご注意ください。
- 2021年1月2日現在、Amazon Textractでは日本語を読み取ることはできません。

## 必要なgemをインストールする

- aws-sdk

## Amazon TextractのClientクラスインスタンスを生成する

リージョンにバージニア北部を指定しているのは、まだ東京リージョン(ap-northeast-1)では提供されていないためです。
これを省略すると、デフォルトのリージョンが適用されてしまい、デフォルトをap-northeast-1にしている場合は、エラーになってしまい使用できません。

```ruby
client = Aws::Textract::Client.new(region: 'us-east-1')
```

AWSの認証情報については[こちら](https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-files.html)をご覧ください。

## ローカルファイルを読み取る

[Amazon Textract ClientクラスのAPIリファレンス](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/Textract/Client.html)を参考にして、テキストを読み取りましょう。

APIリファレンスではS3バケット上のファイルの扱い方も書いてありますが、`bytes`に関しての情報が薄かったので、本記事では、`bytes`について書かせていただきました。

```ruby
detected = client.detect_document_text(document: { bytes: URI.open('sample.png').read })
```

## 参考

- [Amazon Textract ClientクラスのAPIリファレンス](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/Textract/Client.html)
- [AWS CLIでプログラムから参照するにAWSの認証情報の設定などを行う方法](https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-files.html)
soucetreeでAWSCodecommitの登録がエラーになった時の対応方法

Sourcetreeエラー対応方法
Q1　クーロンするときのURLを指定→ソースURLとして正しくありません
原因：別のアカウント認証情報が読み込まれている（codecommit）
対策A：他認証情報を適切な設定にする
方法：
1. 他のcodecommitのURLを使用しているタブ（リポジトリ）へ
2. 設定＞リモート＞configファイルを編集
3. ファイルの一番下に以下を追記→再度元のタブに戻りクーロンを検証
[credential]
helper = /usr/local/bin/aws –profile CodeCommitProfile codecommit credential-helper $@
UseHttpPath = true
参考URL：https://live-cast.asia/blog/2016/06/sourcetree-with-aws-codecommit.html
対策B：対策Aでだめな場合、アカウント内の使用していない認証情報を削除し、再度cloneを行う
方法：
1.  New tabのRemoteから”アカウントを編集”をクリックしアカウント情報の画面へ
2.  ”認証”から不要な認証情報を削除
3.  再度Cloneを実施※認証情報の入力画面が表示される
4. 認証情報を削除したら、別タブでfetch,pullができなくなる場合あり
grep便利コマンド

grepの便利コマンドのまとめていきます。

#### ■ファイル名に「○○」という文字列が含まれているファイルのリストを取得。
```txt:指定フォルダ直下のみ
ls [検索対象フォルダのパス] | grep "[検索したい文字列]"
```

```txt:指定フォルダ配下を再帰検索
find [検索対象フォルダのパス] -type f -name "*[検索したい文字列]*"
```

参考URL：https://qiita.com/pokari_dz/items/0f14a21e3ca3df025d21

#### ■Terraformのリソース名のgrepで収集。

```txt:すでに展開されているawsリソース一覧を検索
terraform show | grep resource.*"aws.*"
```

```txt:すでに展開されているリソースのname一覧を検索
terraform show | grep name.*""
※s3はbucketがnameになるので注意
```
downをし忘れて関係性がわからなくなるったときに使うコマンド


#downをし忘れて関係性がわからなくなる
docker-compose down

#以下を削除すればcomposeで作成したものの大半はなくなるはず
###注意事項
docker container pruneはなるべく使わないほうが無難
###docker ps -aで表示される稼働していないコンテナを全て削除する。。
docker rm <コンテナ名orコンテナID>
docker rm <コンテナ名orコンテナID>
#ドッカーネットワークの削除
docker network --help
docker network ls
#ドッカーボリュームの削除
docker volume --help
docker volume ls
docker volume prune
#ドッカーイメージの削除
docker image --help
docker images
docker image prune
docker image ls --filter dangling=true
WindowsのWSL2でdeeplabcutのインストールする

# 概要
この記事ではdeeplabcutのインストールに必要なパッケージのインストールするところから、実際にdeeplabcutをインストールするところまで説明します。
ディストリビューションはUbuntu20.04LTSです。あと、全ての処理(学習と推論含む)をプロセッサでやること前提なので悪しからず。

# 必要なパッケージのインストール
deeplabcutをインストールする前に、必要なパッケージをインストールしておきます。ただ、以前に作成した仮想環境を元にしているので、ここで記載しているものも必要かもしれません。

```
$ sudo apt install libsdl1.2debian ubuntu-desktop mesa-utils
```

# deeplabcut環境の構築
Anacondaをインストールします。この記事ではAnacondaを使って、deeplabcutの環境を構築します。deeplabcutはバージョンの依存関係が強いためです(deeplabcutに限らないけど...)。

```
$ wget https://repo.anaconda.com/archive/Anaconda3-2020.11-Linux-x86_64.sh
$ sudo bash Anaconda3-2020.11-Linux-x86_64.sh
# いくつか質問があるので答えてください。
$ source ~/.bashrc
$ conda -V
conda 4.9.2
# インストールできていればバージョンが表示されます。
```

次にpython=3.6で仮想環境を作成して、アクティベートします。

```
$ conda create -n deeplabcut python=3.6
$ source activate deeplabcut
```

仮想環境上で、tensorflowとwxPython、 deeplabuctをインストールします。

```
$ pip install tensorflow==1.14
$ pip install https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-18.04/wxPython-4.0.3-cp36-cp36m-linux_x86_64.whl
$ export LD_LIBRARY_PATH=/root/anaconda3/envs/deeplabcut/lib:$LD_LIBRARY_PATH
$ pip install deeplabcut
```

これでインストールは完了です！
【Rails5】Docker環境での別ブランチからのgit commit失敗の対策

初めてのDocker環境で、Railsアプリを作成中。
別ブランチからのコミットが失敗し解決までに時間がかかったので、
同じエラーが出てもすぐに対処できる様に備忘録として記載します。



##原因
.postgesディレクトリをgit管理していたため

##解決策
・ .gitignoreに.postgresを記載
→その後pushしてもgithubには残ったまま

 [.gitignoreに記載したのに反映されない件](https://qiita.com/fuwamaki/items/3ed021163e50beab7154)
→こちらのページを参考にキャッシュをして、
コミットからpushしたらgithub上から消えました！

その後、別ブランチを作成しコミット、pushまでできたことを確認。

ただ、エラーの出たブランチに切り替えたら、同じエラーが出てしまったので、
今日やってた作業のほとんどは消えてしまいました。。。

また、一から頑張りたいと思います！！

##まとめ
プログラミング初心者の自分なので、
勇気を持ってTeratailに投稿してみましたが、
全然いい答えは帰ってこないのですし、
答えもせず、馬鹿にしてくる様な人が多いので、
今後は自分でエラーを解決できる能力を高めるしかないなと思いました(ｏ'∀')ﾉ