<h2 id="hc69c85bcf9">背景</h2><ul><li>M1 Macの環境にyarnを入れていた</li><li>yarnは <code>npm install -g yarn　</code>でインストールした</li><li>nodenvでnodeのバージョンを管理していた</li></ul><h2 id="h6c3a683b78">どのような問題が起きたか</h2>nodenvでバージョンをv14.17.4に変えてyarnをやろうとしたところ、<pre><code>The `yarn` command exists in these Node versions: v16.13.0
</code></pre>と表示された。つまりyarnコマンドがv16.13.0でしか実行できなかった。<h2 id="hecc60282f8">なぜ起きたか</h2>背景にもある通り、M1 Macの環境構築時、Homebrewがyarn未対応だったためyarnをグローバルにインストールしてしまった。そのため、<pre><code>＄ which yarn
/Users/username/.anyenv/envs/nodenv/shims/yarn
</code></pre>となってしまっていた。<h2 id="h821d19f6cf">[結論]どう解決したか</h2>shimsに入っているyarnを削除。グローバルにインストールしたyarnをuninstall<pre><code>$ npm uninstall -g yarn
</code></pre>さらに、<pre><code># shimを削除
$ rm -rf /Users/username/.anyenv/envs/nodenv/shims/yarn
</code></pre>さらに、<pre><code>sudo rm -rf /Users/amanokokorotarou/.anyenv/envs/nodenv/versions/16.13.0/lib/node_modules/yarn/bin/yarn.js
</code></pre>をする。この状態でyarnを使いたいバージョンにnodenvで移動した上で<pre><code>$ brew install yarn
</code></pre>これで各nodeでyarnを使えるようになった。<pre><code>$ which yarn
/opt/homebrew/bin/yarn
</code></pre><h2 id="hfe874bf3df">結論に至る過程</h2><ul><li><a href="https://bake0937.hatenablog.com/entry/2020/03/01/224852" target="_blank" rel="noopener noreferrer nofollow">yarn コマンドで「The `yarn&apos; command exists in these Node versions:」と表示された場合の対応</a></li><li><a href="https://zenn.dev/catnose99/articles/9356979accca26" target="_blank" rel="noopener noreferrer nofollow">nodenvでglobalパッケージをuninstallできなくなったときの対処法（shimsを削除）</a></li><li><a href="https://zenn.dev/ryuu/scraps/90093ce9b8bd48" target="_blank" rel="noopener noreferrer nofollow">The yarn command exists in these Node versions: と言われたので環境を見直す</a></li><li><a href="https://qiita.com/ClapAndWhistle/items/a5ac200501454e064abb" target="_blank" rel="noopener noreferrer nofollow">nodenv管理下の npm で yarn を install した時に yarn の PATH が通らなかった時の対処メモ</a></li></ul>

nodenv管理下で yarnコマンドを打った時「The `...

題名の通りです。ビルド時にwarnが出て気になったので調べてみたログをメモとして残しておきたいと思います。TailwindCSSをv2からv3にアップデートすると以下のようなwarnが出てくるようになります。<pre><code>warn - The `purge`/`content` options have changed in Tailwind CSS v3.0.
warn - Update your configuration file to eliminate this warning.

warn - The `darkMode` option in your Tailwind CSS configuration is set to `false`, which now behaves the same as `media`.
warn - Change `darkMode` to `media` or remove it entirely.
</code></pre>自分はTailwindCSSのバージョンが2系の時に<pre><code>$ npx tailwindcss init
</code></pre>で設定ファイルを作成し導入していたのでv3にあげた際に上記のwarnが出るようになってしまいました。v2時の<code>tailwind.config.js</code>ファイル<pre><code>module.exports = {
 purge: [&apos;./pages/**/*.{js,ts,jsx,tsx}&apos;, &apos;./components/**/*.{js,ts,jsx,tsx}&apos;],
 darkMode: false, // or &apos;media&apos; or &apos;class&apos;
 theme: {
 extend: {
 backgroundImage: (theme) =&gt; ({
 &apos;pc-bg-img&apos;: &quot;url(&apos;/pc-bg.jpg&apos;)&quot;,
 }),
 },
 },
 variants: {
 extend: {},
 },
 plugins: [],
};
</code></pre>これのpurgeに関する部分とdarkModeに関する部分についてwarnが出ているので解消します。結論、以下のようにするとwarnが解消されました。<pre><code>module.exports = {
 content: [
 &quot;./pages/**/*.{js,ts,jsx,tsx}&quot;,
 &quot;./components/**/*.{js,ts,jsx,tsx}&quot;,
 ],
 darkMode: &quot;media&quot;
 theme: {
 extend: {
 backgroundImage: (theme) =&gt; ({
 &quot;pc-bg-img&quot;: &quot;url(&apos;/pc-bg.jpg&apos;)&quot;,
 }),
 },
 },
 variants: {
 extend: {},
 },
 plugins: [],
};
</code></pre>そして、なんならdarkMode設定しない場合は項目ごと無くしてしまっても良いみたいです。<h2 id="hbccc3dfe5b">補足 TailwindCSSにおけるダークモード</h2>TailwindCSSではダークモードを簡単に有効化することができます。やり方は簡単で、<code>tailwind.config.js</code>ファイルにて、<pre><code>module.exports = {
 purge: [&apos;./public/**/*.html&apos;],
 theme: {
 extend: {},
 },
 variants: {},
 plugins: [],
 darkMode: // &apos;media&apos; or &apos;class&apos;
}
</code></pre>darkModeのプロパティの値をmediaかclassに設定するだけです。mediaに設定するとOSのダークモードの設定値によってダークモードにするかしないかを決定します。classに設定すると手動で切り替えられます。詳細は以下の記事を参照ください。<a href="https://zenn.dev/azukiazusa/articles/bee71756d66679" target="_blank" rel="noopener noreferrer nofollow">Tailwind CSSでダークモード</a>

[TailwindCSS]v2からv3にアップデートした際に...

<h2 id="h9707d3a59a">概要</h2><a href="https://github.com/welldone-software/why-did-you-render" target="_blank" rel="noopener noreferrer nofollow">WhyDidYouRender</a>という不要な再レンダリングを検知してコンソールに出してくれるライブラリを入れると、<pre><code>different React elements (remember that whyDidYouRender.js:
the &lt;jsx/&gt; syntax always produces a *NEW* immutable React
element so a component that receives &lt;jsx/&gt; as props always re-
renders).
</code></pre>というものが出てきました。これがなんで起きているのか、どう解決したのかを自分用のメモとして残しておきます。<h2 id="hcf83e1357e"></h2>実際にこれが起こるサンプルを再現したソースコードを用意しましたのでこちらを基に解説します。<a href="https://github.com/s-amano/rerender-sample">https://github.com/s-amano/rerender-sample</a><h2 id="hcf83e1357e"></h2><h2 id="h48e10acf13">再レンダリングを再現</h2>元となる表示のためのコンポーネント(App.tsx)<pre><code>function App() {
	 const [visible, setVisible] = useState(false);
	 window.setTimeout(() =&gt; setVisible(true), 3000);
	 return (
	 &lt;div className=&quot;App&quot; style={{ display: &apos;flex&apos;, justifyContent: &apos;center&apos;, alignItems: &apos;center&apos; }}&gt;
	 {visible ? &lt;div&gt;loaded&lt;/div&gt; : &lt;div&gt;now loading...&lt;/div&gt;}
	 &lt;Parent&gt;
	 &lt;Children /&gt;
	 &lt;/Parent&gt;
	 &lt;/div&gt;
	 );
	}
</code></pre><code>visible</code> という状態が変化すると、Appコンポーネントは正常な再レンダリングが起きます。ただし、この場合<code>visible</code> の状態に関係がないParentコンポーネントも不要に再レンダリングが起きてしまいます。ここで注目してほしいのは、Parentコンポーネント自体は以下のようにmemo化ができているという点です。親コンポーネント(Parent.tsx)<pre><code>export interface Props {
	 children: JSX.Element;
}

const Parent: React.FC&lt;Props&gt; = React.memo(({ children }) =&gt; {　　// ←ちゃんとmemo化している。
	 console.log(&apos;parent component&apos;);
	 return (
	 &lt;div&gt;
	 &lt;p&gt;Parent&lt;/p&gt;
	 {children}
	 &lt;/div&gt;
	 );
});
</code></pre>Propsとして、コンポーネントを渡しています。子コンポーネント(Children.tsx)<pre><code>const Children: React.FC = () =&gt; {
	 return &lt;div&gt;children component&lt;/div&gt;;
};
</code></pre><h2 id="h39306adb22">なぜ不要な再レンダリングが起きるのか</h2>まず前提として、親コンポーネントが再レンダリングされた時、その配下にある子コンポーネントは全て再レンダリングされてしまいます。また、コンポーネントはPropsがオブジェクトの時、差分がなくても(内容が同じであっても)再レンダリングするという特性があります。→参照: <a href="https://tech.kitchhike.com/entry/react-should-component-update" target="_blank" rel="noopener noreferrer nofollow">コードを読んでやっと理解できた React の shouldComponentUpdate</a>上記のことから、、、Appコンポーネントに再レンダリングが起きるとその配下となるChildrenコンポーネントもレンダリング前と違うものと判定されてしまいます。すると、ChildrenコンポーネントをPropsとして持っているParentコンポーネントから見ると、「propsが変わった」となりParentコンポーネント自体にmemo化がされているにも関わらず再レンダリングしてしまうのです。つまり、Parentコンポーネントに渡しているPropsであるChildrenコンポーネントはReact Elementであり、単なるオブジェクトであるから同様の内容であっても再レンダリングが走るということです。<h2 id="had0b1b94af">解決方法</h2>解決方法自体は至って単純です。AppコンポーネントでChildrenコンポーネントをmemo化するだけです。App.tsx<pre><code>function App() {
 const [visible, setVisible] = useState(false);
 window.setTimeout(() =&gt; setVisible(true), 3000);
 const memorizedChildren = useMemo(() =&gt; &lt;Children /&gt;, []); 　//←ここでmemo化
 return (
 &lt;div
 className=&quot;App&quot;
 style={{
 display: &quot;flex&quot;,
 justifyContent: &quot;center&quot;,
 alignItems: &quot;center&quot;,
 }}
 &gt;
 {visible ? &lt;div&gt;loaded&lt;/div&gt; : &lt;div&gt;now loading...&lt;/div&gt;}
 &lt;Parent&gt;
 {memorizedChildren}
 &lt;/Parent&gt;
 &lt;/div&gt;
 );
}
</code></pre>

[React]Propsにchildrenとしてcompon...

<h1 id="hb6fd360517"># 目的</h1>AWS LambdaでバックエンドAPIを構築しているとき、関数の挙動を確認したいときは都度devにデプロイしていました。流石にローカルでの開発環境を整えたいと思ったのですがGoでの使い方の情報が少なかったので個人メモとしてまとめてみました。今回はAPI GatewayがトリガーのLambda関数になります。→<a href="https://blog.70-10.net/2018/08/29/serverless-typescript/#4-code-classlanguage-textserverless-offlinecode%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%83%AD%E3%83%BC%E3%82%AB%E3%83%AB%E3%81%A7%E5%AE%9F%E8%A1%8C%E3%81%99%E3%82%8B" target="_blank" rel="noopener noreferrer nofollow">serverless invoke local -f &lt;function&gt;で十分らしいです</a><h1 id="h0177c42637"># 全体の流れ</h1>以下のJavascript filesのところを今回はGolangにしてやってみます。引用: <a href="https://qiita.com/noralife/items/e36621ddd0e5b8ff4447#%E6%A7%8B%E6%88%90" target="_blank" rel="noopener noreferrer nofollow">https://qiita.com/noralife/items/e36621ddd0e5b8ff4447#%E6%A7%8B%E6%88%90</a>大まかな流れは以下です。1. DynamoDB Localをインストール&amp;セットアップ2. Serverless offlineをインストール &amp;セットアップ# DynamoDB Localをインストール&amp;セットアップ<h2 id="ha7f3c87dfd">## パッケージインストール</h2><pre><code>$ npm install --save-dev serverless-dynamodb-local
</code></pre><h2 id="h97dc00252e">## serverless.ymlにプラグインを追記</h2><pre><code>```serverless.yml

plugins: 
 - serverless-dynamodb-local

```
</code></pre><h2 id="ha234c3c041">## JDKがなければここでインストール</h2>dynamodb-localのためにはJavaが必要でしたので、ローカルpcにJavaを入れていない方はインストールします。インストールの仕方は、mac osだと、以下が参考になります。<a href="https://qiita.com/suke_masa/items/f9af0fb84ad9447ae961" target="_blank" rel="noopener noreferrer nofollow">https://qiita.com/suke_masa/items/f9af0fb84ad9447ae961</a><h2 id="hfd1ed606f2">## dynamo db localをインストール</h2>serverless.ymlのあるディレクトリにて、<pre><code>```sh
$ sls dynamodb install
```
</code></pre>## カスタム定義<pre><code>```serverless.yml
custom:
  dynamodb:
    stages:
     - dev
    start:
     port: 8000
     inMemory: true
     migrate: true
     seed: true
    seed:
     development:
      sources:
       - table: テーブル名
```
</code></pre>この状態で、<pre><code>```sh
sls dynamodb start
```
</code></pre>でdynamodbがローカルで立ち上がります。<code>http://localhost:8000/shell</code>にアクセスすると管理画面に移れる。シェル例<pre><code>```
var params = {
  TableName: &apos;pr_enqueteform_dev&apos;,
};
dynamodb.scan(params, function(err, data) {
  if (err) ppJson(err);
  else ppJson(data);
});
```
</code></pre><h1 id="h5c90efdc93"># Serverless offlineをインストール &amp;セットアップ</h1>次にローカルでapi gatewayを試すためにServerless offlineをインストールしていきます。<h2 id="ha7f3c87dfd">## パッケージインストール</h2><pre><code>```sh
$ npm install --save-dev serverless-offline
```
</code></pre><h2 id="he1a54a6f78">## serverless.ymlにプラグインを追加</h2><pre><code>```serverless.yml
plugins: 
 - serverless-dynamodb-local
 - serverless-offline ### 追記
```
</code></pre><h2 id="h1e1a1e1023">## カスタム定義</h2><pre><code>```serverless.yml
custom:
 serverless-offline:
  useDocker: true
```
</code></pre>この状態で<pre><code>```sh
$ npx sls offline
```
</code></pre>でローカルで起動できます。※Makefileにて、<pre><code>```sh
$ make local-test
```
</code></pre>を打つことでビルド〜offline起動までやってくれるようにしています。例:<pre><code>```sh
$ npx sls offline
Serverless: Deprecation warning: CLI options definitions were upgraded with &lt;中略&gt;
  ┌───────────────────────────────────────────────────────────────────────────────────────┐
  │                                            │
  │  POST | http://localhost:3000/dev/submit                       │
  │  POST | http://localhost:3000/2015-03-31/functions/EnqueteformReceiver/invocations  │
  │                                            │
  └───────────────────────────────────────────────────────────────────────────────────────┘

offline: [HTTP] server ready: http://localhost:3000 🚀
offline:
offline: Enter &quot;rp&quot; to replay the last request

offline: POST /dev/submit (λ: EnqueteformReceiver)
```
</code></pre>上記みたいな感じになっていたら立ち上がっています🎉<h1 id="he1c3637988"># offlineとdynamodb-localを疎通させる</h1>localでofflineを使ってlambda apiを叩いてログを出力してみると、handlerのeventsの中の、<code>events.APIGatewayProxyRequest.RequestContext.APIID</code>が <code>&quot;offlineContext_apiId&quot;</code>　となっていました。そこで、この部分で判断して、localのdynamodbクライアントを生成するか本番用のdynamodbクライアントを生成するかを条件分岐させることにします。localのdynamodbクライアントの生成方法は以下でやります。<pre><code>```go
func (c *DynamoDBClient) OfflineDynamoDBClient(region string, tableName string) *DynamoDBClient {
	sess := session.Must(session.NewSession())
	config := aws.Config{
		Region: aws.String(region),
		Endpoint: aws.String(&quot;http://host.docker.internal:8000&quot;),
		DisableSSL: aws.Bool(true),
		Credentials: credentials.NewStaticCredentials(&quot;dummy&quot;, &quot;dummy&quot;, &quot;dummy&quot;),
	}

	dynamodbClient := DynamoDBClient{
		tableName: tableName,
		dynamo:  dynamodb.New(sess, &amp;config),
	}

	return &amp;dynamodbClient
}
```
</code></pre>※もっとよい判定方法がありそうな感じです。<h1 id="hc6afa5e752"># 試してみる</h1>ローカルでコードを編集した後、一度ビルドしなければローカルの方にも反映されませんので、<pre><code>```sh
$ make clean
$ make build
$ npx sls offline
```
</code></pre>とします。<h2 id="h7a4b09ca25">## curlで疎通してみる</h2>sls offlineしたターミナルとは別のタブにて、<pre><code>```sh
curl http://localhost:3000/dev/submit -X POST -H &quot;Content-Type: application/json&quot; -d &apos;{&quot;category&quot;:&quot;hogecategory&quot;,&quot;email&quot;:&quot;sample@gmail.com&quot;,&quot;address&quot;:&quot;東京都&quot;, &quot;hoge&quot;:{&quot;id&quot;:&quot;1001&quot;,&quot;text&quot;:&quot;hogehoge&quot;}}&apos;
```
</code></pre>sls offlineしたターミナルのタブにてログが出てくる。<pre><code>```sh
START RequestId: d09*7296d-***-1c72-545b-5**c58d99034 Version: $LATEST

&lt;中略&gt;

END RequestId: d09729?6d-b4e2-1c72-5*45b-5e**ec58d99034
REPORT RequestId: d09?7296d-*b4e2-1c72-545b-5c5*d99034	Init Duration: 189.68 ms	Duration: 5513.25 ms	Billed Duration: 5514 ms	Memory Size: 3008 MB	Max Memory Used: 34 MB
```
</code></pre>実際にローカルのdynamoDBにデータを挿入する関数であれば、<code>http://localhost:8000/shell</code>をみてみると挿入されていることが確認できます！<h1 id="h77cbd11e45"># 参考</h1><a href="https://qiita.com/frozenbonito/items/effcc31ca2117789f0e9" target="_blank" rel="noopener noreferrer nofollow">Serverless Framework での AWS Lambda + Go ローカル開発事情</a><a href="https://qiita.com/noralife/items/e36621ddd0e5b8ff4447" target="_blank" rel="noopener noreferrer nofollow">Serverless アプリケーションをローカルで開発する</a><a href="https://zenn.dev/maruware/articles/cac0052812c2e3293dd5" target="_blank" rel="noopener noreferrer nofollow">serverless framework + TypeScript +DynamoDB のローカル環境</a><a href="https://bearmini.hatenablog.com/entry/2015/10/09/233849" target="_blank" rel="noopener noreferrer nofollow">Go で DynamoDB Local を使った時にいろいろハマったのでメモ</a><a href="https://gist.github.com/Tamal/02776c3e2db7eec73c001225ff52e827" target="_blank" rel="noopener noreferrer nofollow">example</a>