こんばんは。この度Next.js+ Vercel + TailwindCSS + microCMSの構成でブログを公開しましたので、ブログを公開するまでの手順をメモとして残しておきたいと思います。<h2 id="hf22588e3d7">そもそも</h2><h2 id="hcf83e1357e"></h2>

Next.js + Vercel + TailwindCSS + microCM...

<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 `yarn` command exists in these Node versions:」と出た[M1Mac]

題名の通りです。ビルド時に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にアップデートした際に出るwarnの解消

<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としてcomponentを渡している際に起こる不要な再レンダリング

2021年11月の1カ月間株式会社サイバーエージェントさんでフロントエンドエンジニアとしてインターンをしてました。今更感はありますが、やったことや学んだことや感想など自分用のメモとしてまとめておきます。<h2 id="h1388d7e348">採用まで</h2>インターン採用までの流れとしては、ES選考 → 一次面接 → 二次面接 → 参加という感じでした。面接では自分が書いたESを基に非常に雰囲気良く会話形式で進んでいきました。二次面接の終わりに「インターン参加していただきます」と言われたので少し驚きました。その後、配属先のメンターの方との面談を経て実際に11月から実務へ移るという形になりました。私が配属されたのは<a href="https://dokusho-ojikan.jp/" target="_blank" rel="noopener noreferrer nofollow">Amebaマンガ</a>という事業でした。<h2 id="h2220f0ef7d">やったこと</h2>端的にいうと、Webフロントエンドのパフォーマンス改善を行いました。<a href="https://developers.cyberagent.co.jp/blog/archives/30577/" target="_blank" rel="noopener noreferrer nofollow">CLS改善をした結果事業成果がグンと上がった話</a>こちらの記事にもある「SpeedCurveを垣間見る会」にも参加させていただきました。指標を見る→課題を見つける→考察&amp;改善方法を検証する→タスク化→実装とリリース→指標を見るというフローを経験できました。その中で、今回僕が行なったのは大まかに分けて<ul><li>マイページのCLS改善</li><li>Reactにおける再レンダリング対策</li></ul>です。それぞれ簡単に解説しようかと思います。<h3 id="hfed09d2cbb">マイページのCLS改善</h3>CLSとはGoogleの提唱する<a href="https://developers-jp.googleblog.com/2020/05/web-vitals.html" target="_blank" rel="noopener noreferrer nofollow">Core Web Vitals</a> の1つです。よくある体験としては、「送信ボタン」みたいなものをタップしようとしたら広告が入り込んできて広告をタップしちゃうみたいなことです。今回マイページにおいてCLSが起こってしまっていた原因は、データのローディング中とロード後で要素の大きさが変わるためでした。そこで、ロード後に来るであろう要素を先にスケルトンという形で用意しておく、というものです。スケルトンについては<a href="https://engineering.linecorp.com/ja/blog/front-end-otoshidama/" target="_blank" rel="noopener noreferrer nofollow">こちらの記事</a>が分かりやすいかと思います。実際にCLSの数値が改善されており嬉しかったのを覚えています。<h3 id="h3404c5c538">Reactにおける再レンダリング対策</h3>whyDidYouRenderというライブラリで不要に再レンダリングが起こってしまっている箇所を修正しました。ここではなぜ不要に再レンダリングが起こってしまっているかの調査から原因を特定し、解決策を考え実装し、なぜその解決策で上手くいったのかというところまで体験できたので非常に楽しかったです。これについては別記事で詳しく述べたいと思います。<a href="https://10shin.net/blogs/s263wet-7" target="_blank" rel="noopener noreferrer nofollow">→書きました</a><h2 id="h447d69583c">学んだこと</h2>今までのインターンや個人開発では小さめのプロダクトが多かったので、初めて大規模な開発に携わったため学ぶことが非常に多かったです。また、技術的な学びだけでなくマインド面での気づきが多かったように思います。<h3 id="h5db61149aa">大規模開発における設計や実装と開発フロー</h3>単に設計と言ってもその時点のベストプラクティスとか最新でモダンな技術を取り入れたら良いいいわけではなく、URL共存しなきゃいけないとか人材の確保の容易さとかのビジネス要件も考慮する必要があるというのは新たな発見でした。そのときのリーダーの思想によって設計が変わったりすることがあったり全ソースコードまで目が通せなかったりというのは大規模開発ならではだと思いました。また、commitメッセージがテンプレート化されていたり、commit時にlinterが走ったり多くのコメントがあったり、変数名に規則性があったりと大規模開発をする上で整備されると望ましい部分についても学ぶことができました。<h3 id="hf72e369568">なぜそうなるかまで考えて実装する</h3><h3 id="hcf83e1357e"></h3>memo化すれば再レンダリングさせなくできる、でそのままタスクは終了することは出来ますが、それが何故なのか原因は何かまで掘り下げることでその部分の修正だけでなくもっと抽象的に全体の修正に応用ができ、結果的に全体でみると近道でさえあるという良い経験ができました。このように思考しながら実装することで未知の問題に当たったときの引き出しも増えると思うのでこの考え方は大事にしたいと思います。<h3 id="h529054f8d5">Webパフォーマンスについて</h3>Webパフォーマンスについてどのような態度で向き合うか理解が深まりました。数値を見たときにそれが何故その数値になっているか考察するという点が重要だなのだと学びました。LCPの数値悪くなっていたが、例え数値が悪くなっていたとしてもクーポン訴求が起因だった場合、事業的優先度を踏まえると現状は難しいので原因把握に留めておく、とか、再レンダリング修正の実装が長期的に見て徐々にメモリ利用減少に繋がっているのではないか、みたいな事例を「SpeedCurveを垣間見る会」で経験できたので良かったです。<h3 id="hde9197008c">マインド面</h3>自分から積極的に人と関わり前に出て何かに参加することはビジネス職、エンジニア職関わらず大事なのだと学びました。今までもなんとなくそういう人って評価されるよねという実感こそあったのですが、なぜそのような人が評価されるのか、チームや会社にとってプラスになるのかまで少しだけ理解できた気がします。例えばある部署で良い知見を得たときにそれを全社向けに発信できる人がいるとプラスになるし、人と積極的に関わりを持っているとある問題を解決するときにこの問題なら他部署の〇〇さんが詳しいから聞けるかもみたいなこともできるなと思いました。粛々とタスクをこなすだけでは人と人から生まれるシナジー効果が薄れるという点でもっと能動的に人を巻き込んで行動することの重要性を学びました。<h2 id="h1cb1ed03f9">待遇や環境や感想</h2>時給は1500円でした。交通費も実費で出ました。コロナ禍ということもあり、出社は週3だったのですが、もれなく出社日には美味しいランチへ連れて行っていただきました。渋谷の美味しいランチは制覇した気でいます()また、本当にいい人、いい方が多いという印象を持ちました。とにかく雰囲気が良く、質問すればタスクに関係ないことでも気さくに答えてくださったり、業務外のことでも優しく話しかけてくださったため参加前に不安だった気持ちは1日目にはなくなっていました。また、どうすれば私が1つでも多く学びを多く持ち帰れるか、という視点でタスクを振ってくださったり、毎週メンターさんと人事の方とミーティングが組まれており、そこで自分に足りない点やアドバイスをくれたりなどとにかく素晴らしい体験となりました。偉そうなことは言えませんが、参加するか迷っている方がいたら絶対に参加した方が良いと思います！

サイバーエージェント社のインターンに行ってきた

<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>

AWSLambda(Golang)×DynamoDBのローカル開発環境を整える

<h2 id="h09f1fa4532">何がやりたかったか</h2>こういうやつ↓<h2 id="hcf83e1357e"></h2>リストがあって、それを特定個で区切ってページごとに表示するやつです。ページネーションとかナビゲーションとか言ったりするやつです。結論から言うと、よくある3ページ目、5ページ目などの特定のページへ飛べるページネーションはおそらく実装不可能です。上記画像のように次のインデックス前のインデックスなどでしかできません。こういうやつ↓<h2 id="h8a175a9b0e">前提</h2><ul><li>Lambdaでの、AWS SDK for Goを利用</li><li>フロントはReactを利用</li></ul>※dynamoDBの基本的な動作の説明はございません。※とりあえずロジック考えて動けば良いかなで実装したので絶対もっと良い方法があるはずな気はしています<h2 id="he6c8d05d55">何が大変だったのか</h2>結論から言うと、DynamoDBがこういう検索の仕方を想定していないせいです。(多分)DynamoDBには一応ページネーション的な機能はあるのですが、<a href="https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Query.Pagination.html" target="_blank" rel="noopener noreferrer nofollow">テーブルクエリ結果をページ分割する</a>これはあくまでDynamoDBが一度に取得できる1MBサイズの縛りを超えて全ての件数を**1回のコールで**取得したいときの実例です。(この縛りもDynamoDBの罠な気がする)利用方法としては、取得したい個数を`Limit`で指定できるので、これを指定し、`LastEvaluatedKey`に取得したいアイテムの1つ前のアイテムを指定するという方法です。さらにフロントからは、<ul><li>全件取得で件数を取得</li><li>6で割ってページネーションが全体で何ページになるか計算</li><li>現在のページをstateで管理</li><li>全件取得したアイテムを6こずつ区切った配列を用意</li><li>現在のページから考えて、上記の区切った配列の最後の要素のidをGetAPIのクエリに混ぜて新しい6個を取得</li></ul>という面倒なことをやらなければなりません。<a href="https://note.com/ryoppei/n/n2c381f434069" target="_blank" rel="noopener noreferrer nofollow">参考リンク</a><h2 id="h59f744c0be">実際のコード</h2><a href="https://github.com/s-amano/unknown-diary/blob/9d86699b71f68d53c8d9a284f719648b30f28fa3/backend/comconfirm-lambda/functions/diary-my-getter/domain/get-my-diary.go#L112" target="_blank" rel="noopener noreferrer nofollow">自分のプロダクトにおける使い方バックエンド</a><a href="https://github.com/s-amano/unknown-diary/blob/9d86699b71f68d53c8d9a284f719648b30f28fa3/React/unknwon-react-diary/src/component/FetchMyDiaries.js#L75" target="_blank" rel="noopener noreferrer nofollow">自分のプロダクトにおける使い方フロントエンド</a>以下はバックエンド側のサンプルですが、割と端折ってます。詳細は上記のソースコードを読んでみてください。詳細は<a href="https://docs.aws.amazon.com/sdk-for-go/api/service/dynamodb/#QueryInput" target="_blank" rel="noopener noreferrer nofollow">公式ドキュメント</a>を参考にしてください。まずクエリで送られてきたidをもとに該当idのアイテムを取得しておく。(itemとする)6個取得したいとき<pre><code>type QueryInput struct {
 ...
 Limit *int64 `min:&quot;1&quot; type:&quot;integer&quot;`
 ExclusiveStartKey map[string]*AttributeValue `type:&quot;map&quot;`
}
// ExclusiveStartKeyに取得したいアイテムの1つ前のアイテムのidなどの項目を指定する
//　フロントから取得したいアイテムの1つ前のidを送ってもらう
// 取得しておいたitemからexclusiveStartKeyを作る

exclusiveStartKey = map[string]*dynamodb.AttributeValue{
 &quot;id&quot;: {
  S: aws.String(*item[&quot;id&quot;].S),
  },
 &quot;post_at&quot;: {
  N: aws.String(*item[&quot;post_at&quot;].N),
  },
}
</code></pre>ここでの注意点は、グローバルインデックスで検索をかけている場合は、この指定するExclusiveStartKeyもパーティションキーとソートキーだけでなく、そちらのキーたちも必要になります。

DynamoDBのwebでのページネーションが苦行だったメモ

<h2 id="he2485005d0">目的</h2>APIの処理をAPIを叩いてきたユーザー名によって変えたいということがありました。そこで、Cognitoでオーソライズを行っているLambda関数にて、API Gatewayの認証情報をLambda(Golang)の中で取得する方法を調べました。<h2 id="hcb9dacb773">結論</h2>以下のコードでユーザー名を取得できます。<pre><code class="language-go">func handler(ctx context.Context, apiGWEvent events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) {

	ユーザー名取得
	diaryGetter := apiGWEvent.RequestContext.Authorizer[&quot;claims&quot;].(map[string]interface{})[&quot;cognito:username&quot;].(string)

  /// ...略
}
</code></pre>割と途中のコードとかが謎ですので、以下に解説を載せておきます。(これより単純に取得できる方法がありましたらご教授いただけると幸いです。)<h2 id="hc499e4ad38">解説</h2>(前提として、LambdaのオーソライザーにCognitoのユーザープールが設定されていることを確認)まず、events.APIGatewayProxyRequestにはどのようなhttpリクエストを受け取ったのかが格納されます。ドキュメントを参照すると、<pre><code class="language-go">type APIGatewayProxyRequest struct {
  Resource            string            `json:&quot;resource&quot;` // The resource path defined in API Gateway
  Path              string            `json:&quot;path&quot;`   // The url path for the caller
  HTTPMethod           string            `json:&quot;httpMethod&quot;`
  Headers             map[string]string       `json:&quot;headers&quot;`
  MultiValueHeaders        map[string][]string      `json:&quot;multiValueHeaders&quot;`
  QueryStringParameters      map[string]string       `json:&quot;queryStringParameters&quot;`
  MultiValueQueryStringParameters map[string][]string      `json:&quot;multiValueQueryStringParameters&quot;`
  PathParameters         map[string]string       `json:&quot;pathParameters&quot;`
  StageVariables         map[string]string       `json:&quot;stageVariables&quot;`
  RequestContext         APIGatewayProxyRequestContext `json:&quot;requestContext&quot;`
  Body              string            `json:&quot;body&quot;`
  IsBase64Encoded         bool             `json:&quot;isBase64Encoded,omitempty&quot;`
}
</code></pre>となっております。参考:[<a href="https://qiita.com/saki-engineering/items/e5cf56301d94ceea3ce0" target="_blank" rel="noopener noreferrer nofollow">GoDoc package aws/aws-lambda-go/events</a>]参考:[<a href="https://qiita.com/saki-engineering/items/e5cf56301d94ceea3ce0" target="_blank" rel="noopener noreferrer nofollow">AWS Lambda+API Gateway+DynamoDBでCRUD APIを作るのをGolangでやってみた</a>]こちらの、RequestContext構造体には、Authorizer情報が`map[string]interface{}`型で入っています。僕が作成したアプリのdev環境用のCognitoの情報を取得してみると、以下の様になっています。<pre><code class="language-go">map[claims:map[aud:tekitoutekitou auth_time:12345678 cognito:username:テスト太郎 event_id:tekitou-d37c-41c9-be67-tekitou exp:Tue May 11 14:18:46 UTC 2021 iat:Tue May 11 13:18:46 UTC 2021 iss:https://cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-tekitou sub:tekitou-c7e9-4649-ab16-tekitou token_use:id]]
</code></pre>こちらから、claimsキーの中の、cognito:usernameキーがユーザーネームであることがわかります。最初この構造を見たとき、<pre><code class="language-go">diaryGetter := apiGWEvent.RequestContext.Authorizer[&quot;claims&quot;][&quot;cognito:username&quot;]
</code></pre>みたいな感じでとれるんじゃないの？と思ったのですが、これをやろうとすると、<pre><code>invalid operation: cannot index apiGWEvent.RequestContext.Authorizer[&quot;claims&quot;] (map index expression of type interface{})
</code></pre>となってしまいます。interface型の知識が欠如しておりました。&gt; どんな型の値でも受け取れるinterface{}ですが、interface{}型の引数で受け渡された値は、元の型の情報が欠落しています。（元の型の値を操作するための関数等を実行できません）引用:<a href="https://blog.y-yuki.net/entry/2017/05/08/000000">https://blog.y-yuki.net/entry/2017/05/08/000000</a>元の型の値を操作できないため、辞書型のキーを取り出すという動作ができないっぽいです。なので、型アサーションをして、取り出す必要がありました。さらにこの`diaryGetter`はstring型として扱いたいので、最後も型アサーションをする必要があったということです。まず、<pre><code class="language-go">apiGWEvent.RequestContext.Authorizer[&quot;claims&quot;]
</code></pre>を型アサーションで`map[string]interface{}`型にして、mapのキーを取り出すという感じです。

AWS Cognitoでユーザー情報をAWS Lambda(Golang)から取得する方法

TwitterやLINEなどでリンクを貼った時、OGPの設定をしていればタイトル、画像、概要などをカードのような形で表示できるようになります。逆に設定していないとせっかくリンクを共有しても目に止まらない可能性が高いです。OGPが動的というのは、例えばブログ記事のidによってタイトル、画像、概要を出し分けるということです。ということでNext.jsで作成したサイトで動的OGPを作成する方法についてのメモです。<h2 id="h40b4e638d1">コンポーネント作る</h2>まずはOGP用のコンポーネントをnext/headを使って作っていきます。<a href="https://qiita.com/TK-C/items/cd34d0f6d4b001053443" target="_blank" rel="noopener noreferrer nofollow">こちらのサイトを参考にさせていただきました。</a><pre><code class="language-typescript">import Head from &apos;next/head&apos;;

const Seo = ({ pageTitle, pageDescription, pagePath, pageImg, pageImgWidth, pageImgHeight }) =&gt; {
 const defaultTitle = &apos;サンプル&apos;;
 const defaultDescription = &apos;サンプルディスクリプション&apos;;
 const defautlImg = &apos;https://sample.jp/sample-logo.png&apos;;

 const title = pageTitle ? `${pageTitle} | ${defaultTitle}` : defaultTitle;
 const description = pageDescription ? pageDescription : defaultDescription;
 const url = pagePath;
 const imgUrl = pageImg ? pageImg : defautlImg;
 const imgWidth = pageImgWidth ? pageImgWidth : 1200;
 const imgHeight = pageImgHeight ? pageImgHeight : 630;

 return (
 &lt;Head&gt;
 &lt;title&gt;{title}&lt;/title&gt;
 &lt;meta name=&quot;viewport&quot; content=&quot;width=device-width,initial-scale=1.0&quot; /&gt;
 &lt;meta name=&quot;description&quot; content={description} /&gt;
 &lt;meta property=&quot;og:url&quot; content={url} /&gt;
 &lt;meta property=&quot;og:title&quot; content={title} /&gt;
 &lt;meta property=&quot;og:site_name&quot; content={title} /&gt;
 &lt;meta property=&quot;og:description&quot; content={description} /&gt;
 &lt;meta property=&quot;og:type&quot; content=&quot;website&quot; /&gt;
 &lt;meta property=&quot;og:image&quot; content={imgUrl} /&gt;
 &lt;meta property=&quot;og:image:width&quot; content={String(imgWidth)} /&gt;
 &lt;meta property=&quot;og:image:height&quot; content={String(imgHeight)} /&gt;
 &lt;link rel=&quot;preconnect&quot; href=&quot;https://fonts.gstatic.com&quot; /&gt;
 &lt;link
 href=&quot;https://fonts.googleapis.com/css?family=Roboto:100,300,400,500,700,900&amp;amp;display=swap&quot;
 rel=&quot;stylesheet&quot;
 /&gt;
 &lt;link rel=&quot;canonical&quot; href={url} /&gt;
 &lt;/Head&gt;
 );
};

export default Seo;
</code></pre>こちらをトップページに埋め込むととりあえずはOGPが設定された状態になります。これをブログ記事によって変えたいのであれば、propsに値を渡すことで可能になります。<pre><code class="language-typescript">import Layout from &apos;../components/Layout&apos;;
import Seo from &apos;../components/SeoOgp&apos;;

export default function Home({ blog, totalCount }) {
 return (
 &lt;Layout title=&quot;Home&quot;&gt;
 &lt;Seo /&gt;
 &lt;/Layout&gt;
 );
}
</code></pre>このように設定します。例えば、ブログ記事の情報に変えたいなら、blogs/[id].jsなどのファイルで、<pre><code class="language-typescript">import Layout from &apos;../../components/Layout&apos;;
import Seo from &apos;../../components/SeoOgp&apos;;

export default function BlogId({ blog }) {
 return (
 &lt;Layout title=&quot;blog&quot;&gt;
 &lt;Seo
 pageTitle={blog.title}
 pageDescription={blog.body}
 pageImg={blog.image.url}
 pageImgWidth={1280}
 pageImgHeight={960}
 /&gt;
 &lt;/Layout&gt;
 );
}
</code></pre>などとします。