みなさんお久しぶりです！
株式会社ナレッジワークのソフトウェアエンジニアのはぎはらです！
本記事では2024年3月28日に開催した勉強会 Encraft #12 Frontend Quiz Night の開催レポートをお届けいたします。
https://knowledgework.connpass.com/event/311056/

 Encraftとは？
Encraft（エンクラフト）は株式会社ナレッジワークが提供する、 "Enablement" と "Craftsmanship" をテーマにした勉強会です。技術にこだわりを持つ人々が集まって互いに知見を交換し、できることを増やしてい...

Encraft #12「Frontend Quiz Night」開催レポート

今回で3回目の開催となった「Encraft #3」の開催レポートをお届けします！


 Encraftとは？
Encraft（エンクラフト）は株式会社ナレッジワークが提供する、 "Enablement" と "Craftsmanship" をテーマにした勉強会です。技術にこだわりを持つ人々が集まって互いに知見を交換し、できることを増やしていく場を作りたいと思っています。
過去のイベントの開催レポートは以下からご覧ください。

Encraft #1「フロントエンド × 設計」開催レポート
Encraft #2「サーバーとクラインアントを結ぶ技術」開催レポート

今回もオフラインで参加するこ...

Encraft #3「エンジニアイネーブルメント - 共有・育成・評価・効率化 -」開催レポート

urqlで無限ローディングなUIを実装する方法がググってもそのまま真似できそうなパターンがあまり出てこなかったので記録しておこうと思います。
基本方針としてはドキュメントに書いてあるとおりに従います。
https://formidable.com/open-source/urql/docs/basics/ui-patterns/#infinite-scrolling

 前提条件
以下の記事で紹介している無限スクロールのための汎用hookを使います。
https://zenn.dev/eringiv3/articles/70d20a2eeacf2e

 実装
リストの最後の要素が画面内に...

urqlで無限ローディングUIを実装する

無限スクロール/ローディングなUIを作る機会が多いので、共通化できる部分をhooksにして再利用できるようにしました。
IntersectionObserverを使ってリストの最後の要素の位置を判定して次ページのコンテンツを読み込むなどの処理を実現したいときに使えます。
import { useEffect, useRef, useState } from 'react'

export const useInfiniteScroll = (
  loadNextPage: () =&gt; void,
  options?: IntersectionObserverInit
) =&g...

無限スクロール/ローディングなUIを作る機会が多いので、共通化できる部分をhooksにして再利用できるようにしました。
IntersectionObserverを使ってリストの最後の要素の位置を判定して次ページのコンテンツを読み込むなどの処理を実現したいときに使えます。
import { useEffect, useRef, useState } from 'react'

export const useInfiniteScroll = (
  loadNextPage: () => void,
  options?: IntersectionObserverInit
) =&g...

無限スクロール/ローディングなUIを作るときの汎用hooks

<p>転職して1年が経ちました。<br>転職するにあたってそれなりに期待や目標をもっていたので、1年経ったこのタイミングで振り返りをしてみようと思います。<br>転職する時に書いた記事は以下です。<br><a href="https://www.eringiv3.dev/posts/jbkcpob5q" target="_blank" rel="noopener noreferrer">https://www.eringiv3.dev/posts/jbkcpob5q</a><br></p><h2 id="h8d192aad07">転職してから何をやっていたか</h2><p>新規事業のプロダクト開発を入社してから今までずっと続けています。<br>PM1人、バックエンドの開発者1人、フロントエンドの開発者1人(自分)という構成で開発しています。<br>スモールチームで価値を発揮できるようになりたいと思っていたので、いまの環境は自分にとって望む方向に成長できる環境です。<br>新規事業なので、何もないところから開発を始めて途中で何度かピボットもありましたが、現在もリリースに向けて開発を続けています。<br>初めての転職、初めてのリモートワークということで最初の一ヶ月は結構しんどかった記憶があります。<br>分からないことは気軽に質問できる環境ではあったのですが、フロントエンドの開発者は自分1人ということで、自力で全部なんとかしなきゃいけないというのがプレッシャーでした。<br>前職ではフロントエンドだけで開発者が10人くらいいるチームで働いていたので、自由を得た反面、責任は増えたことを実感しました。<br>また、受託開発と違い、自社サービスの開発なので、自分が開発しているモノで売上を立てなければいけないというプレッシャーもあります。<br>受託開発は納期との闘いですが、自社サービスもさっさとリリースして売り上げを立てるようにしなければいけないので全然ぬるま湯なんかではありませんでした。<br>ですが、フロントエンドのことは1年間なんでも自力でこなしてきたので、とにかく動くものを作る！作ったものを見せてフィードバックをもらう！このサイクルを回す力はだいぶついたと思います。<br>一口にフロントエンドといってもめちゃくちゃ範囲が広いのですが、ウェブアプリケーションを作る上でのフロントエンドに関する業務は大体なんとかこなせるようになってきました。<br>ずっと0→1のできるエンジニアになりたいと思っていて、フロントエンド領域に関してはそれができるようになってきた感触が確実にあります。<br></p><h2 id="hdf41eaca89">転職前に感じていた不満は解消されたか</h2><p>転職前に感じていた不満は主に、</p><ul><li>自分の身につけたいスキルが身につけられない環境だったこと</li><li>開発プロセスについて不満があったこと</li></ul><p>の2点です。<br><br>結論としては、どちらも解消することができました。<br><br>1点目の「自分の身につけたいスキルが身につけられない環境だったこと」については、サーバーサイドのテンプレートエンジン + jQueryの環境を抜け出すことができて、宣言的UI(React)で快適に開発することができています。<br>これに関しては、新規事業でフロントエンドの開発者が自分1人だったことにより、技術選定を自分1人の責任で行えたことが大きかったと思います。<br>試したい技術、取り入れたい技術があれば素振りする→使えそうなら仕事でも取り入れてみるというサイクルを回すことができました。<br>そのせいで苦労したこともありました(SWRと Recoilの両方で同じserver stateを管理してバグを生み出したりとか)。しかし、開発者が1人なので自分のケツは自分で拭かなければならず、自分の決断に対して反省をするタイミングが何度もありました。<br>自分の決断に対して反省する、というのは前職では出来なかった経験です(反省が必要になるほどの太い経験ができる実務が降ってこなかった)。<br>そのため、これはポジティブに捉えています。これからも反省を繰り返していくことになるでしょう。<br><br>2つ目の「開発プロセスに不満があったこと」については、あまり意味を感じない設計業務から解放されたことにより解消されました。<br>前職では SIerと仕事をしていたこともありExcelで画面設計書を作っていたりしました。<br>どこからデータを取ってくるだとか、なんのパラメータを付けて画面遷移するだとか、ソースコードレベルで表現できれば十分じゃないか？ということまで設計書に落とすことを求められていて、変更があるたび膨大な設計者変更が必要でうんざりしていました。<br>それよりもソースコードの品質を保つことに時間をかける方が有意義に思います(ドキュメントが大事ではないと言っているのはではなく、ドキュメントに残すべきこととソースコードで表現すべきことをバランスよく分けて考えた方がいいのではということです)。<br>現職では、Excelで設計書を作るといったプロセスは一切なく、Slackで議論し必要であればコンフルエンスに残すといった最低限の運用でなんとかなっています。また、動くものを作って触ってもらうというサイクルを高頻度でできているのも個人的には良いなと思っている点です。<br></p><h2 id="h4ae13a11b1">転職前に期待していた事はどうだったか</h2><p>転職前に期待していた事は3つありました。<br></p><h3 id="hca444b658b"><strong>自分が関わるプロダクトに自信と責任を持って開発できること</strong></h3><p>責任を持って開発することという点については達成できています。先ほども書きましたが、フロントエンドを1人でやっているのでフロントエンドの開発の責任は全て自分に振ってきます。<br>自信を持って開発するという点については、まだまだかなあという印象です。<br>自分の書いたプログラムはバグが少ないですと堂々と言えるくらいにならないといけないと思います。<br></p><h3 id="h8bbf462715"><strong>エンジニアとして求められる生産性のハードルが低すぎないこと</strong></h3><p>こちらは概ね達成できていると思います。<br>転職してから、実装したことのないUIをたくさん実装してきました。そのおかげで、今では実装したことのないUIを目にしても自分ならこう実装するかなというのをある程度イメージできるようになりました。<br>よほど複雑なUIでなければ実現できるだろうという自信がつきました。これは決して低くないハードルを乗り越え続けてこれたからだと思います。<br></p><h3 id="h9e99a868f8"><strong>生活する上でそんなに我慢することなく暮らせるだけのお金がもらえること</strong></h3><p>これも達成できました。<br>お金は重要です。前職の時と比べて年収で+100万弱くらいの給料を頂いています。余裕を持って生活ができるようになりました。<br>新卒の頃は年収300万以下だったのでかなりカツカツでした。<br>また、転職して1年経ち頑張りを認めてもらえたのかSOをもらうこともできました。<br>このまま上場まで突っ走るのみです！<br></p><h2 id="h240a0d4dab">結局転職して良かったか</h2><p>とても良かったです。転職したことによってリモートワークにもなって、生活も良くなったように思います。残業や休日出勤もなくなりましたし、QOLが確実に上がりました。<br>仕事内容にも満足していて、楽しく働くことができています。<br>悩みといえば、リモートワークきっかけで腰を痛めてしまったことくらいです。<br>今後について<br>いまの目標は、</p><ul><li>会社が上場できるよう貢献する</li><li>開発中の新規事業をリリースして売り上げをたてる</li></ul><p>の2点です。<br>また、もうすぐ新卒3年目の年が終わります。そろそろジュニアエンジニアではなく、中堅エンジニアといった立ち位置になってきそうです。<br>Twitterを見ていると自分と同じかそれよりも下の年代で自分よりも遥かに凄い実績を積み立てている人も多く見かけます。<br>その度に自分は何もできてないなと思ったりもするのですが、必要な努力ができていないので当たり前です。<br>3年弱エンジニアとして生きてみて、自分は生活を犠牲にしてまでプログラミングにのめり込むというのがそんなにできる性格ではないというのが分かりました。<br>幸い、ソフトウェアエンジニアという職業は住む場所や生活の時間のバランスを調整しやすい職業です。<br>次の3年間は自分にとってどう生きるのがより幸せなのか、探求していく年になりそうです。<br>引き続き、仕事も人生も頑張っていきたいです。健康第一で！<br><br>以上！</p>

転職して1年経ったので振り返り


 モチベーション

SvelteでWeb Componentsを作りたい
作ったWeb ComponentsをCDNで配布して、ブラウザから読み込んで使えるようにしたい

サードパーティーのスクリプトを作るのにSvelteが適している理由は以下の記事にわかりやすくまとめられています。
https://zenn.dev/mizchi/articles/8a017097d3994ddc0a85

 SvelteでWeb Componentsをつくる
CounterコンポーネントとClockコンポーネントの計2つのコンポーネントを作ります。
まずはViteでアプリケーションの雛形をつくります...

SvelteでWeb Componentsを作成し、CDNから配布して使う

以前、以下の記事で個人開発に適した最強のアーキテクチャについて考えました。
https://zenn.dev/eringiv3/articles/c44d5400e5603e
上記で考察したアーキテクチャで実際にサービスを作ってリリースするところまでいったので、実際に最強だったかどうかをいくつかの観点から振り返ってみようと思います。

 作ったもの
以下のサービスを作ってリリースしました。
一言で説明すると、ジーンズを好きな人が自分の育てたジーンズを記録することのできるサービスです。
https://www.denitz.net/

 アーキテクチャ
以前書いた記事で紹介したアーキテクチ...

ぼくのかんがえたさいきょうの個人開発アーキテクチャで実際にサービスをリリースしたので振り返りをする

Amplify ConsoleでNext.jsのISRするコードをデプロイしたときに、revalidateに指定した秒数が経過した後の再生成が行われず、ISRするページが503エラーになる事象に困らされました。
この事象が発生する理由と対処方法について記録します。

 再生成が行われない理由
結論は、Default Lambda@Edge for Next CloudFront distributionからNext.js Regeneration Lambdaを発火させるためのSQSに対してのメッセージ送信に失敗していたためです。
まず、Amplify ConsoleがNext.jsをデ...

Amplify ConsoleでNext.js ISRの再生成が失敗するときの対処法

<p>ブログを作り直しました。<br>1年ほど前にGatsby.jsで作ったブログがあったのですが、それを今回Next.jsで作り直しました。理由は、見た目とコードがショボくていじる気が失せてたためです。<br>一年前はまだ仕事でReact/TypeScriptを書いた経験がなく、今見返すと良いコードとは言えないものでした。<br>転職もして、仕事で毎日React/TypeScriptを書いてる今ならもっとまともなものが作れるなと思い、勢いで作り替えました。<br></p><h2 id="h683a3334db">主な技術スタック</h2><ul><li>Next.js</li><li>Chakra UI</li><li>microCMS</li></ul><h2 id="h135ab76aa0">前回のブログとは変えた点</h2><ul><li>Zennのフィードも表示するようにした</li><li>記事一覧のページネーションをやめた</li><li>動的OGPをimgixのAPIを使って生成するようにした</li><li>記事検索機能を追加した</li><li>プロフィールページをNotionで管理するようにした</li></ul><p>などです。<br><br>作るにあたって工夫した点はあまりなくて、ひたすら楽をして作りたいという気持ちで作りました。<br>見た目に関してはChakra UIのコンポーネントをそのまま使って色を変えてるだけですし、ページネーションについては実装がめんどくさいので1ページに全記事表示するようにしました。<br>というかJAMStackなんだからビルド時に全記事のデータ取得するしページネーション作ってページを分けて表示する必要ってあるんでしょうか？<br>何千記事とかあるなら話は変わってくると思いますが(サーバーから取得するHTMLのサイズが膨れ上がるので)、100記事にも満たないこのブログではページネーションは不要だと判断しました。<br>使う側としても1ページに全記事載ってる方が嬉しくないでしょうか？InstagramとかTwitterもそうですけど、ひたすら縦にスクロールしていく無限スクロール/ローディングのUIが今では当たり前な感じがします。<br>Zennのフィード表示はRSSを使って実現しています。<br>動的OGPについて、以前作ったブログでは、<a href="https://www.npmjs.com/package/node-ogp-creator" target="_blank" rel="noopener noreferrer">node-ogp-creator</a>という自作のパッケージを使ってビルド時にOGP画像を生成してたのですが、Next.jsと相性が良くない気がして(public配下にwriteFileするのってあんま見かけないし気が進まなかった)使うのをやめました。<br>その代わりにmicroCMSのブログで紹介されていたimgixのAPIを使ってOGP画像を生成する方法に変えました。使い方は<a href="https://blog.microcms.io/imgix-ogp/https://blog.microcms.io/imgix-ogp/" target="_blank" rel="noopener noreferrer">microCMSのブログ記事</a>を見ていただければなんとなくわかると思います。はっきりいってimgixは動的OGP生成の救世主です。めちゃくちゃ便利だし、今後も使いたいと思いました。APIがちょっと理解しづらい気がするのが難点ですが。<br>あと、記事検索機能についてですが、Algoliaのような外部サービスは使いませんでした。<br>Next.jsのstatic propsで全記事のタイトルを渡すようにしておいて、それに対して入力された文字列で部分一致で検索をかけるようにしています。</p><pre><code>import { SearchIcon } from '@chakra-ui/icons';
import {
  Box,
  Heading,
  Input,
  InputGroup,
  InputRightElement,
} from '@chakra-ui/react';
import { GetStaticProps, InferGetStaticPropsType, NextPage } from 'next';
import { NextSeo } from 'next-seo';
import React, { useState } from 'react';
import FeedCard from '../components/FeedCard';
import Layout from '../components/Layout';
import PostCard from '../components/PostCard';
import { getAllContents, isMicrocmsPost } from '../lib/microcms';
import { getZennFeedItems } from '../lib/zenn';
import type { PostListResponse, PostResponse, ZennFeedItem } from '../types';
import { sortByDate } from '../utils/arrayHelpers';


type StaticProps = {
  postOrFeedList: (PostResponse | ZennFeedItem)[];
};
type PageProps = InferGetStaticPropsType&lt;typeof getStaticProps&gt;;
const Search: NextPage&lt;PageProps&gt; = ({ postOrFeedList }) =&gt; {
  const [value, setValue] = useState('');


  const handleChange = (e: React.ChangeEvent&lt;HTMLInputElement&gt;) =&gt; {
    setValue(e.target.value);
  };


  const hitList =
    value === ''
      ? []
      : postOrFeedList.filter((v) =&gt; {
          const searchTarget = v.title.toLowerCase();
          return searchTarget.includes(value.toLowerCase());
        });


  return (
    &lt;&gt;
      &lt;NextSeo title="記事検索" description="記事検索ページです" /&gt;
      &lt;Layout&gt;
        &lt;InputGroup&gt;
          &lt;Input placeholder="記事タイトルを検索" onChange={handleChange} /&gt;
          &lt;InputRightElement&gt;
            &lt;SearchIcon /&gt;
          &lt;/InputRightElement&gt;
        &lt;/InputGroup&gt;
        &lt;Box marginTop="10"&gt;
          {hitList.length !== 0 ? (
            &lt;Heading as="h1" color="blue.700"&gt;
              検索結果
            &lt;/Heading&gt;
          ) : value !== '' ? (
            &lt;Box&gt;記事が見つかりませんでした。&lt;/Box&gt;
          ) : null}
          &lt;Box marginTop="5"&gt;
            {hitList.map((postOrFeed, i) =&gt;
              isMicrocmsPost(postOrFeed) ? (
                &lt;PostCard key={postOrFeed.id} post={postOrFeed} /&gt;
              ) : (
                &lt;FeedCard key={i} feedItem={postOrFeed} /&gt;
              )
            )}
          &lt;/Box&gt;
        &lt;/Box&gt;
      &lt;/Layout&gt;
    &lt;/&gt;
  );
};


export const getStaticProps: GetStaticProps&lt;StaticProps&gt; = async () =&gt; {
  const allPostList = await getAllContents&lt;PostListResponse&gt;('post');
  const postList = allPostList.flatMap((postList) =&gt; postList.contents);
  const zennFeed = await getZennFeedItems();
  const postOrFeedList = [...postList, ...zennFeed];
  postOrFeedList.sort(sortByDate);


  return {
    props: {
      postOrFeedList,
    },
    revalidate: 60,
  };
};


export default Search;


</code></pre><p><br>最後に、プロフィールページについてはmicro CMSでプロフィールのコンテンツを管理するのをやめました。プロフィールって割と頻繁に更新する可能性のあるコンテンツだと思うので、気軽に編集できることが望ましいです。<br>microCMSでもスマホから編集できないことはないですが、UIとか操作性、ネイティブアプリの有無などを考えて、Notionでプロフィールを管理することにしました。ブログにはNotionの公開ページのリンクを貼るだけにしています。<br>これからはプロフィールを編集したくなってもスマホのNotionのアプリからお手軽に編集できるのでちゃんと内容を更新できそうです。前のブログでは転職したのに半年近く放置してしまってました。<br>以下が今回新しく作成したNotionのページです。<br><a href="https://hallowed-axolotl-164.notion.site/093e624f4786477f94ac2d2f28de5988" target="_blank" rel="noopener noreferrer">https://hallowed-axolotl-164.notion.site/093e624f4786477f94ac2d2f28de5988</a><br><br>こんな感じで新しいブログは大体3〜4日くらいでリプレイスできました。<br>普段から使い慣れてるNext.jsとUIで楽するためのChakra UIを使ったことでかなり早く実装できた気がします。<br>見た目に関しても自分の好きなインディゴっぽいカラーで雰囲気を統一することができて満足です。<br>ドメインもdev.eringiv3.comからeringiv3.devに変更しました。やっぱdevドメインの方がエンジニアのブログ感出ていいですよね。<br><br>ソースコードも公開してるので気になる方は見ていただければと思います。<br><a href="https://github.com/EringiV3/devBlog_V2" target="_blank" rel="noopener noreferrer">https://github.com/EringiV3/devBlog_V2</a><br><br>古い記事の中で他の記事を参照してるリンクがリンク切れしてしまっていますが、今は直す気力がないので多分しばらくこのままです…。気が向いたら直します。</p>

ブログを作り直した

この本では、TypeScriptで型安全にGraphQLサーバーを構築する方法をハンズオン形式で学習することができます。
Todoアプリの開発を通して、GraphQLスキーマの扱いやCLIツールの設定方法、TypeScriptのORMであるPrismaの基本的な使用方法、CI/CDパイプラインの構築によるマイグレーションの自動化などを体験します。
GraphQLサーバー実装の素振りをしておきたい方や、フロントエンドからGraphQL APIを使用したことはあるけど自分でAPIを実装したことはないようなバックエンドの開発初心者の方に向けた内容となっております。


Apollo ServerとPrismaではじめるGraphQL API開発入門

一番下までスクロールされたら次ページ分のコンテンツを読み込んで追加で表示する、といった無限ローディングの実装を行うときにハマったので記録しておきます。

 最小限の動作する例
import React, { useEffect, useRef, useState } from 'react';
import useSWRInfinite from 'swr/infinite';

const fetcher = (url: string) =&gt; fetch(url).then((res) =&gt; res.json());
const PAGE_SIZE = 10;

const...

一番下までスクロールされたら次ページ分のコンテンツを読み込んで追加で表示する、といった無限ローディングの実装を行うときにハマったので記録しておきます。

 最小限の動作する例
import React, { useEffect, useRef, useState } from 'react';
import useSWRInfinite from 'swr/infinite';

const fetcher = (url: string) => fetch(url).then((res) => res.json());
const PAGE_SIZE = 10;

const...

IntersectionObserverとSWRで無限ローディングを実装するときはuseRefに気をつけよう

フロントエンドアプリケーションの開発を行う上で避けては通れないデータフェッチの実装。
REST APIを使うか、GraphQLを使うか、クライアントでキャッシュするか、APIレスポンスにどのようにして型を付けるか、状態管理はどうするのかなど、開発者の悩みが尽きないけれども、それに関しての設計を考えたり議論を行うのはフロントエンド開発の楽しいポイントだと僕は思っています。
この記事では、バックエンドにHasura、フロントエンドにNext.jsを使用する場合に僕が最強だと感じたツールの組み合わせ・使い方を紹介します。

 モチベーション

APIからのレスポンスにはTypeScriptの型...

ぼくのかんがえたさいきょうのデータフェッチ 2021Summer🏄‍♂️【Next.js / Hasura】


 前置き
この記事で紹介するアーキテクチャはあくまで机上論であり、筆者が実際にこれらのアーキテクチャでサービスを運用したことがあるわけではありません。
そのため、考慮漏れ等あるかもしれません。その際はご指摘いただけますと幸いです。

 モチベーション

個人開発でアプリケーションを作って運用したい！
お金は極力かけたくない！
けどいい感じのツールを組み合わせてクールなアーキテクチャにしたい！


 対象とするアプリケーションの概要

ブラウザで動くウェブアプリケーション
認証機能を持つ
DBはNoSQLではなくRDB
アプリケーション本体とは別に管理画面アプリケーションが必要

以上を...

ぼくのかんがえたさいきょうの個人開発あーきてくちゃ

<p>以下の記事でGoogle App EngineにTwitter Botをデプロイしましたが、GAEの制約（HTTPリクエストが10分間来なかったらインスタンスがシャットダウンされる）を知らなかったため、24時間常に起動していてほしいBotのデプロイ先としては適していないことがわかりました。<br><a href="https://dev.eringiv3.com/blog/post/github_actions_google_app_engine_ci_cd" target="_blank" rel="noopener noreferrer">GitHub Actions と Google App Engine でCI/CD</a><br><br>今回は、そのリベンジとしてGCEにデプロイして、問題なく動かすことができました。<br>CI/CDの自動化まで行ったので、手順を記録します。<br></p><h2 id="ha88dc2a453">ゴール</h2><ul><li>GCEにコンテナ化したアプリケーションをデプロイして動かすことができる</li><li>デプロイを自動化する</li></ul><p><br></p><h2 id="h6cce74c095">アプリケーションのDocker化</h2><p>以下の記事に別途まとめました。<br><a href="https://dev.eringiv3.com/blog/post/run_typescript_app_on_docker_container" target="_blank" rel="noopener noreferrer">TypeScriptで作ったアプリケーションをコンテナで実行する</a><br></p><h2 id="h4ee84e6ac6">まずは手動でGCEにコンテナをデプロイしてみる</h2><h3 id="he0a3ad0c4f">GCP Container Registory にイメージをpushする</h3><p>ローカル環境でビルドしたDockerイメージをContainer Registoryにpushします。<br>次のステップで、GCEのインスタンスをたてるときにイメージを指定するためです。<br><br>ローカルのイメージにレジストリ名をタグ付けします。ホストはasia, イメージ名にはappを指定しました。</p><pre><code>docker tag [IMAGE_NAME] asia.gcr.io/[PROJECT-ID]/app</code></pre><p><br>タグ付けされたイメージをContainer Registoryにpushします。</p><pre><code>docker push HOSTNAME/PROJECT-ID/IMAGE</code></pre><p><br></p><h3 id="h33b5353ef5">GCEインスタンスにコンテナをデプロイする</h3><p>Google Cloud Consoleから、Compute Engineの管理画面に行き、「インスタンスを作成」→「コンテナイメージをデプロイ」を選択します。<br>コンテナイメージには、先程pushしたイメージを指定します。<br>また、環境変数もここで設定可能です。<br>マシンタイプには「f1-micro」を指定しました。f1-microには無料枠があるので、1台までなら無料で使用できるようです。<br>ここまでできたら、「作成」をクリックでインスタンスが作成されます。<br>ちなみに、「コンテナイメージをデプロイ」を選択すると、Compute EngineのOSには、Docker コンテナの実行に最適化されたContainer-Optimized OSというOSが自動で選択されます。<br><br>以上で、手動で単一のコンテナをGCEにデプロイすることができました。<br></p><h2 id="h2007d5f3b4">デプロイを自動化する</h2><p>GitHub Actions を使って、masterブランチへのpush毎に、イメージのビルド・push、GCEのコンテナの更新を行うようにします。<br>buildのジョブでイメージのビルド・pushを行います。<br>deployのジョブでコンテナの更新を行います。<br><code>gcloud compute instances update-container</code> コマンドで、インスタンスの停止→再起動と、起動時に新しいイメージをダウンロードしてコンテナの起動まで行ってくれます。</p><pre><code>name: CI/CD

on:
  push:
    branches: [master]

env:
  IMAGE: asia.gcr.io/dev-article-twitter-bot/app:${{ github.sha }}

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        os: [ubuntu-latest]
        node-version: [14.x]
    steps:
      - name: checkout the repository
        uses: actions/checkout@v2

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}

      - name: yarn install, and test
        run: |
          yarn
          yarn test
        env:
          CI: true

  build:
    runs-on: ubuntu-latest
    steps:
      - name: checkout the repository
        uses: actions/checkout@v2

      - name: set up Cloud SDK
        uses: google-github-actions/setup-gcloud@master
        with:
          project_id: ${{ secrets.GCP_PROJECT_ID }}
          service_account_key: ${{ secrets.GCP_SA_KEY }}
          export_default_credentials: true

      - name: configure docker to use the gcloud cli
        run: gcloud auth configure-docker --quiet

      - name: build a docker image
        run: docker build . -t $IMAGE

      - name: push the docker image
        run: docker push $IMAGE

  deploy:
    needs: [test, build]
    runs-on: ubuntu-latest
    steps:
      - name: set up Cloud SDK
        uses: google-github-actions/setup-gcloud@master
        with:
          project_id: ${{ secrets.GCP_PROJECT_ID }}
          service_account_key: ${{ secrets.GCP_SA_KEY }}
          export_default_credentials: true

      - name: set project
        run: gcloud config set project $GCP_PROJECT_ID
        env:
          GCP_PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }}

      - name: deploy to GCE
        run: gcloud compute instances update-container $GCP_PROJECT_ID --container-image $IMAGE --zone=us-west1-b
        env:
          GCP_PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }}</code></pre><p><br>以上でデプロイの自動化までできました！<br></p><h2 id="h57d3da36fb">できあがったもの</h2><p>dev.toの公開記事取得APIを使用して、リプライで受け取った単語を検索キーワードとし、ヒットした記事のタイトルとリンクをリアルタイムにリプライするTwitter Botです。<br>よかったら使ってみてください。<br><a href="https://twitter.com/dev_reply_bot" target="_blank" rel="noopener noreferrer">https://twitter.com/dev_reply_bot</a><br><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/04671489f65e6484665e9d1e5f2e7494/dfdba771d07b08bb507b54a4e5ae8855.png" alt=""><br></p><h2 id="h88876ec3b5">リポジトリ</h2><p><a href="https://github.com/EringiV3/dev-article-reply-twitter-bot" target="_blank" rel="noopener noreferrer">https://github.com/EringiV3/dev-article-reply-twitter-bot</a><br></p><h2 id="h8d78e14043">感想</h2><p>gcloudコマンドがとても便利で、デプロイの自動化も特に詰まることなくできました。<br>コマンド一つでGCEインスタンス上のコンテナ更新できるの凄いです。<br>ただ、GCEにデプロイできるコンテナは1つまでらしいので、複数のコンテナをデプロイする必要がある場合はGoogle Kubernetes Engineを使用してくださいと公式のドキュメントに書いてありました。<br>GCPのドキュメントは丁寧かつ知識のない人でも読みやすいようにできていて、これからもGCPを積極的に使いたいという気持ちになります。<br>GAE, GCEにデプロイするワークフローの作成を体験できたので、次なにかデプロイするときはCloud Runを使ってみたいです。<br>常時起動しておく必要があるアプリケーションの場合は、GAEは向かず、GCEのほうが適していることはわかりましたが、HTTPリクエストのたびに起動すればよいアプリケーションの場合、GAEとCloud Runどちらが適しているか、手を動かして理解したくなりました。<br></p><h2 id="h3de35099b3">参考</h2><p><a href="https://cloud.google.com/compute/docs/containers/deploying-containers?hl=ja#console" target="_blank" rel="noopener noreferrer">VM と MIG へのコンテナのデプロイ</a><br><a href="https://cloud.google.com/container-registry/docs/pushing-and-pulling?hl=ja" target="_blank" rel="noopener noreferrer">イメージの push と pull</a></p>

Twitter BotをGoogle Compute Engineにコンテナとしてデプロイするまで

<p>TypeScriptで書いたアプリケーションをコンテナにしてデプロイしたくなったのでやり方を記録します。<br>今回作ったアプリケーションはTwitterのBotなので、HTTPリクエストを起点に起動するアプリケーションではなく、常時起動していてタイムラインをストリーミングするようなものです。<br>そのため、ポートフォワーディングはしていません。<br>HTTPリクエストを受け取るアプリケーションの場合は、ポートの割当が必要となります。<br><br>Dockerfile</p><pre><code>FROM node:14 AS builder
WORKDIR /app
COPY package*.json ./
RUN yarn install
COPY . .
RUN yarn build

FROM node:14 AS runner
WORKDIR /app
COPY --from=builder app/dist ./dist
COPY package*.json ./
RUN yarn install --production
# COPY .env ./
CMD ["yarn", "start"]</code></pre><p><br>ビルド</p><pre><code>docker build . -t [IMAGE_NAME]</code></pre><p><br>実行</p><pre><code>docker run -it --rm --name [CONTAINER_NAME] [IMAGE_NAME]</code></pre><p><br>ビルド結果のイメージを軽くするために、マルチステージビルドを行います。<br>builderでは、devDependenciesを含めたすべての依存をインストールし、TypeScript → Node.jsへのコンパイルを行います。<br>runnerでは、builderでコンパイルされた成果物のdistディレクトリをコピーし、dependenciesの依存だけをインストールします。<br>成果物として得られるイメージには、コンパイル後のJSファイル、package(-lock).json、node_modules(dependenciesのみ)が含まれます。<br>コンテナを実行すると、<code>yarn start</code>が実行されてアプリケーションが起動します。<br><br>環境変数については、デプロイする環境によって、アプリケーションに注入する方法が異なると思います。<br>開発時は、ローカル環境で作成した.envをコンテナ内にコピーすることで動かしています。<br></p><h2 id="h3de35099b3">参考</h2><p><a href="https://nodejs.org/ja/docs/guides/nodejs-docker-webapp/" target="_blank" rel="noopener noreferrer">Node.js Web アプリケーションを Docker 化する</a><br><a href="https://future-architect.github.io/typescript-guide/deploy.html" target="_blank" rel="noopener noreferrer">成果物のデプロイ</a></p>

TypeScriptで作ったアプリケーションをコンテナで実行する

<p>「<a href="https://www.amazon.co.jp/dp/B07L3MX199/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1" target="_blank" rel="noopener noreferrer">スッキリわかるSQL入門</a>」という本を読んでSQLを勉強しました。<br>業務でSQLを書いたことがなく、ORMを介したDBの操作も行なったこともない、フロントエンドの開発経験しかないので、バックエンドの入門としてまずSQLから理解していくことにしました。<br></p><h2 id="hac84e4e38d">モチベーション</h2><ul><li>業務でSQLを使う際に基礎的なレベルで躓かないようにしておきたい</li><li>素のSQLクエリをある程度書けるようになることで、ORMを使ってDBの操作を行うときにアンチパターンを踏まないようにしたい</li><li>JavaScript/TypeScriptのORMである<a href="https://www.prisma.io/" target="_blank" rel="noopener noreferrer">Prisma</a>を理解して使えるようになりたい</li></ul><p><br></p><h2 id="hd84d0d1d3a">SQLについて</h2><p>多くのwebアプリケーションはバックエンドに永続層としてDBを持つことで、データを永続化します。<br>DBには、複数の表形式でデータを管理するRDBと、キーバリュー形式でデータを管理するNoSQLがあります。<br>RDBに対するデータの取り出し・削除・更新・追加等の操作を行うための言語がSQLです。<br>バックエンドのシステム(何かしらのプログラミング言語で構築されたアプリケーション)がORMを介してSQLクエリを発行し、RDBMSがそれを受け取り、データベースの操作を行うという構成が一般的ではないかと思います。<br></p><h2 id="hedad0f0dd3">RDBMSについて</h2><p>RDBMSには、商用製品として分類されるものとOSSとして分類されるものがあります。<br>商用製品だと、Oracle dDB, SQL Serverあたりは聞いたことあるなという感じでした。<br>OSSだと、MySQL, PostgreSQLあたりがフロントエンドしかやったことない自分でもよく聞くなという感じです。<br>RDBMSには、製品によって扱えるデータ型や関数や演算子等に違いがあるため、使うRDBMSの特徴はある程度押さえておく必要がありそうです。<br></p><h2 id="h047448c961">SQLクエリの書き方について</h2><ul><li>4大命令</li><li>関数と式</li><li>集計</li><li>副問い合わせ</li><li>結合</li></ul><p>について章ごとに図解でわかりやすく説明されており、章末に練習問題があります。<br>そして、この本にはクエリを書くだけで実際にDBへの操作を実行できる環境が用意されているので、手を動かして試すことができます（自分はあまり使いませんでした）。<br>更に巻末にドリルと題してSQLクエリを書く問題が合計215問あり、これをやることでだいぶ定着した感覚があります。<br>題材として、銀行口座、商店、RPGゲームのテーブルが用意されています。<br>後半は副問合せと結合を合わせて使うような問題もあり、結構複雑なクエリも要求されます。<br></p><h2 id="h91b539a5b8">DBが永続層としての品質を担保できている仕組み</h2><p>RDBMSは、複数のSQL文を意味のある単位でまとめたものをトランザクションとして扱います。<br>RDBMSは、トランザクションの途中で処理が中断されないようにしたり、他の処理が割り込めないようにしたりといった制御を行います。<br>トランザクションに含まれるすべてのSQLは、「すべての実行が完了している」か、「1つも実行されていない」のどちらかの状態を持ちます。<br>トランザクション内のすべてのSQL文の実行が完了したときにコミットを行うことで、変更内容を確定します。<br>トランザクション内のいずれかのSQL文の実行中にエラーが起こっても、RDBMSがロールバックを行うことで変更内容をなかったことにします。<br>これらの仕組みがあるため、たとえRDBMSを動かすサーバーに災害により電源が落ちてしまうなどの事象が起こってしまったとしても、再起動時に自動的にロールバックが行われて整合性が担保されます。<br></p><h2 id="h8d78e14043">感想</h2><p>この本は、「基礎的なSQLクエリがそれなりに書けるようになること」という目的にフォーカスした本です。<br>DB設計やパフォーマンスチューニングなどについても最低限は触れられています。ただ、実務で必要なレベルまで踏み込まれているかどうかは不明です（自分では判断ができない）。<br>ただ、「データが入っているテーブルを眺めながらSQLクエリを書く」という能力を伸ばすという点についてはかなりの成長が期待できそうです。自分は割と自身がつきました。<br>特に巻末についているドリル215問が良かったです。<br>また、特定のRDBMSに特化したSQLクエリの書き方については、別途理解する必要があります。<br>といっても、本編の内容が理解出来ていればRDBMS依存の記法に慣れるのは簡単そうです。巻末に各RDBMSの互換性についての説明もついています。<br>SQL初心者向けの本としては、とても良い一冊だと個人的には思います。<br>そして、個人的にずっと疑問だった「DBに何が起こっても整合性を保ち続けるための仕組み」について理解できたのが嬉しかったです。<br>SQLをある程度書けるようになったことで、バックエンドへの恐怖感が多少は薄くなった気がします。</p>

「スッキリわかるSQL入門」を読んでSQLを勉強した

<p>最近GitHub Actionsを触り始めました。<br>リポジトリで発生したイベントをトリガーに処理したり、JavaScriptでActionを作ってパッケージにして公開できたり、かなり遊べそうな感じなのですが、まずはベーシックな使い方としてCI/CDパイプラインを構築してみたので記録します。<br></p><h2 id="h051675172a">アプリケーション</h2><p>TypeScript(Node.js)で作ったTwitter botのアプリケーションを対象とします。<br></p><h2 id="h0d376e5d4e">構成</h2><p><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/6f800aed52b87e3f6939f78b23188c2e/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202021-01-17%2020.21.18.png" alt=""><br></p><pre><code>name: Node.js CI


on:
  push:
    branches: [master]


jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        os: [ubuntu-latest]
        node-version: [12.x]
    steps:
      - uses: actions/checkout@v2


      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}


      - name: yarn install, and test
        run: |
          yarn
          yarn test
        env:
          CI: true
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2


      - name: yarn install and build
        run: |
          yarn
          yarn build


      - name: upload dist
        uses: actions/upload-artifact@main
        with:
          name: dist
          path: dist
  deploy:
    needs: [test, build]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2


      - name: douwnload dist
        uses: actions/download-artifact@main
        with:
          name: dist
          path: dist


      - name: Set up Cloud SDK
        uses: google-github-actions/setup-gcloud@master
        with:
          project_id: ${{ secrets.GCP_PROJECT_ID }}
          service_account_key: ${{ secrets.GCP_SA_KEY }}
          export_default_credentials: true


      - name: Setup Node.js
        uses: actions/setup-node@v1
        with:
          node-version: "12.x"


      - name: Load Env Variables
        run: node ./ci/load-env-variables.js
        env:
          APP_TWITTER_COSUMER_KEY: ${{ secrets.APP_TWITTER_COSUMER_KEY}}
          APP_TWITTER_COSUMER_SECRET: ${{ secrets.APP_TWITTER_COSUMER_SECRET}}
          APP_TWITTER_TOKEN_KEY: ${{ secrets.APP_TWITTER_TOKEN_KEY}}
          APP_TWITTER_TOKEN_SECRET: ${{ secrets.APP_TWITTER_TOKEN_SECRET}}
          APP_TWITTER_BOT_ACCOUNT_ID: ${{ secrets.APP_TWITTER_BOT_ACCOUNT_ID}}


      - name: Deploy App to GAE
        run: |
          gcloud app deploy
          rm -f app.yaml</code></pre><p><br></p><ul><li>masterブランチへのpushをトリガーにワークフローが起動します。</li><li>test, build, deployというJobによって構成されます。</li><li>test, buildは並列で実行されます。deployはtest, buildの完了をもって実行が開始されます。</li></ul><p><br></p><h3 id="h77ebeed133">test</h3><p>jestを実行します。今回はユニットテストしか行っていませんが、静的解析ツールによるチェックなどを入れてもいいでしょう。<br>strategy.matrixに、テストを実行する環境の組み合わせ（OS, 言語のバージョン）を指定することで複数の環境でのテストを実行可能です。<br>今回はUbuntu, Node.12.xで指定しました。<br></p><h3 id="he48418e812">build</h3><p>yarn build（中身はtscでのコンパイル）で、コンパイル済みの成果物（distディレクトリ）を出力します。<br>distディレクトリはdeployステップで必要なので、artifactとしてアップロードしておきます。<br>生成されたdistはJob間で共有することができないためです。<br>アップロードされたartifactは、ワークフローの詳細画面からダウンロードすることもできるようです。<br></p><h3 id="h2cea75c696">deploy</h3><p><code>needs</code>に、test, buildを指定しているため、test, buildのJobが完了してから実行されます。<br>buildでアップロードされたartifact(distディレクトリ)をダウンロードします。<br>次に、GCPのCloud SDKの初期化を行います。<br>初期化処理は、それ用のアクションが提供されているので使いましょう。<br><a href="https://github.com/google-github-actions/setup-gcloud" target="_blank" rel="noopener noreferrer">https://github.com/google-github-actions/setup-gcloud</a><br><code>GCP_SA_KEY</code>には、GCP管理画面から取得できる秘匿情報のjsonをbase64でエンコードした文字列を指定します。<br>secretsはリポジトリのsettingsから設定可能です。<br>その後、secretsに設定された環境変数を<code>app.yaml</code>に埋め込みます。<br>最終的に<code>gcloud app deploy</code>するときに参照される<code>app.yaml</code>にアプリケーションで使用する環境変数を指定する必要があるのですが、APIキーなどはGitの管理下に置くことができません。<br>そのため、環境変数の値の部分だけを置換用の文字列で設定した<code>app.template.yaml</code>を用意しておき、デプロイ直前に置換用の文字列をsecretsで取得した値で置き換えることで、バージョン管理に晒すことなくアプリケーションに環境変数を注入します。<br>このやり方は以下のブログで紹介されており、参考にさせていただきました。<br><a href="https://www.anoriqq.com/mask-env-from-github-actions-and-deploy-to-gae" target="_blank" rel="noopener noreferrer">GitHub Actionsから環境変数をマスクしてGAEにデプロイする</a><br>最後は、<code>gcloud app deploy</code>で完了です。<br><br>デプロイが完了すると、GCP管理画面から新しいバージョンが追加されていることが確認できます。<br><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/c9a2e2d12e6549b5c1db74aaa1645da8/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202021-01-17%2021.04.00.png" alt=""><br></p><h2 id="h28e1663de4">作成したワークフロー</h2><p><a href="https://github.com/EringiV3/dev-article-reply-twitter-bot/blob/master/.github/workflows/node.js.yml" target="_blank" rel="noopener noreferrer">https://github.com/EringiV3/dev-article-reply-twitter-bot/blob/master/.github/workflows/node.js.yml</a><br></p><h2 id="h61defdffe2">感想とワークフローがお蔵入りした理由</h2><p>肝心のアプリケーションが仕様的にGAEとマッチしていなかったため、このワークフローはお蔵入りになってしまったのですが、GitHub Actionsを使ってGAEにデプロイしたくなるときがいつか来そうな気がしたので記事にしました。<br>Node.jsの実行環境としてのGAEはとてもお手軽で便利だと感じたので、手持ちの弾にしておきたいです。<br>スタンダード環境だと最初からNode.js（この記事書いた時点では12.x）が入っていて、言語のセットアップをすることなくNode.jsアプリケーションを動かすことができます。<br>しかもスタンダード環境はある程度までは無料で使える！<br>静的なサイト作成時やNext.jsを使うときは、それらに特化したプラットフォーム(NetlifyやVercel)を使ったほうが良さそうですが、素のNode.jsでなにかやりたいときはGAEかなり良さそうです。<br>ただ、GAEはデフォルトの自動スケーリング（<a href="https://cloud.google.com/appengine/docs/standard/nodejs/how-instances-are-managed?hl=ja" target="_blank" rel="noopener noreferrer">https://cloud.google.com/appengine/docs/standard/nodejs/how-instances-are-managed?hl=ja</a>）だと、HTTPリクエストが10分来ないとシャットダウンされてしまいます。<br>今回デプロイしたアプリケーションは、Twitterのタイムラインをストリーミングして特定の条件を満たすツイートが流れてきたらアクションするものだったので、アプリケーションは常に稼働状態である必要がありました。そのため、GAEの制約がある実行環境ではうまく動作しませんでした（デプロイされたサーバーにHTTPリクエストしてから10分間しか動かない）。<br>アプリケーションの仕様をよく考えず、実行環境の選定をしてしまった結果踏んでしまった間違いだと言えます。<br>セットアップの手間が増えますが、GCE(Google Compute Engine)でうまくできないか実験してみます。<br>それでもダメそうなら、おとなしくラズパイ買ってお家サーバー立てて運用しようと思います。。<br></p>

GitHub Actions と Google App Engine でCI/CD

<p>Node.jsのバージョン管理には、今までnodebrewを使っていました。<br>しかし、コマンドの使い方が全然覚えられなかったため、よりシンプルに使えそうなnに乗り換えました。<br></p><h2 id="h6d6d837bce">n</h2><p><a href="https://github.com/tj/n" target="_blank" rel="noopener noreferrer">https://github.com/tj/n</a><br></p><h3 id="he4b21a21c7">インストール方法</h3><p>Node.jsがマシンにすでにインストールされている場合</p><pre><code>npm install -g n</code></pre><p><br>Node.jsがマシンにインストールされていない場合</p><pre><code>curl -L https://git.io/n-install | bash</code></pre><p><br>n -V でバージョンが確認できたらインストールは完了です。</p><pre><code>$ n -V
6.8.0</code></pre><p><br></p><h3 id="ha0e95c0643">使用方法</h3><p>特定バージョンのダウンロード&amp;インストール</p><pre><code>n {version}</code></pre><p><br>ダウンロード済みのバージョン一覧から選択してインストール</p><pre><code>n</code></pre><p><br>特定バージョンの削除</p><pre><code>n rm {version}</code></pre><p><br></p><h3 id="hdadc0eaacf">特徴</h3><p>とにかくシンプルに使えることを念頭に作られている感じがします。<br>GitHubにも「<span style="color:#24292e">Node.js version management: no subshells, no profile setup, no convoluted API, just&nbsp;</span><strong style="color:#24292e">simple</strong><span style="color:#24292e">.</span>」と、シンプルさを強調しています。<br>Node.jsのバージョン管理ツールは、自分が知ってる範囲だと他にもnvm, nodenv, nodebrewなどがあります。<br>nodenvは、ディレクトリ移動時に自動的にバージョンを切り替えることができるようです。<br>自分は、バージョンの切り替えは暗黙的ではなく、明示的に自分で行いたかったのでnodenvは選択しませんでした。<br>nvm, nodebrew, nについては、どれをとってもできることはそんなに変わらないと思うのですが、個人的に一番シンプルなのはnだと感じました。<br></p><h2 id="h8d78e14043">感想</h2><p>シンプルなインターフェイスが好きな方にはnがおすすめです。</p>

Node.jsのバージョン管理にnを使う

<p>ShopifyでStoreFront APIを使用してカスタムECフロントを構築するときに必要なアクセストークンの取得方法に迷ったので記録しておきます。<br></p><h2 id="h45e205c088">プライベートアプリの作成</h2><p><span style="color:#2b2e2f">パートナーアカウントの管理画面からではなく、開発ストアの管理画面から操作を行う。</span><br>開発ストア管理画面にて「アプリ管理」の「プライベートアプリを管理する」をクリック。<br>プライベートアプリを有効にしていない場合は、プライベートアプリを有効にする。<br>プライベートアプリを作成し、<span style="color:#212326">アプリからアクセスするストアのエリアを設定する（後から変更可能）。</span><br><strong style="color:#212326;background-color:#ffffff">[このアプリがストアフロントのAPIを使用してストアフロントデータにアクセスできるようにする]</strong><span style="color:#212326">&nbsp;を選択する（後から変更可能）。</span><br><span style="color:#212326">保存すると、アクセストークンが表示される。</span><br><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/ff3fc7602dd674490b1aedc31ccf263c/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202021-01-10%2017.33.28.png" alt=""><br></p><h2 id="h820121bfb3">疎通確認</h2><p>curlで疎通確認する。レスポンスが帰ってくれば問題無し。</p><pre><code>$ curl -X POST \
&gt; "https://eringiv3test.myshopify.com/api/2020-10/graphql" \
&gt; -H "Accept: application/json" \
&gt; -H "Content-Type: application/graphql" \
&gt; -H "X-Shopify-Storefront-Access-Token: &lt;storefront-access-token&gt;" \
&gt; -d '
&gt; {
&gt;&nbsp; &nbsp;shop {
&gt;&nbsp; &nbsp; &nbsp;name
&gt;&nbsp; &nbsp; &nbsp;primaryDomain {
&gt;&nbsp; &nbsp; &nbsp; &nbsp;url
&gt;&nbsp; &nbsp; &nbsp; &nbsp;host
&gt;&nbsp; &nbsp; &nbsp;}
&gt;&nbsp; &nbsp;}
&gt; }
&gt; '
{"data":{"shop":{"name":"eringiv3test","primaryDomain":{"url":"https:\/\/eringiv3test.myshopify.com","host":"eringiv3test.myshopify.com"}}}}</code></pre><p><br></p><h2 id="h282b720588">関連リンク</h2><p>storefront api document: <a href="https://shopify.dev/docs/storefront-api" target="_blank" rel="noopener noreferrer">https://shopify.dev/docs/storefront-api</a><br></p><h2 id="h3de35099b3">参考</h2><p><a href="https://help.shopify.com/ja/manual/apps/private-apps" target="_blank" rel="noopener noreferrer">https://help.shopify.com/ja/manual/apps/private-apps</a></p>

Shopify StoreFront AccessTokenの取得方法

<p>技術書展10で「いまからはじめるSvelte3」という本を購入して読みました。<br><a href="https://techbookfest.org/product/4925576424980480?productVariantID=5094401858600960" target="_blank" rel="noopener noreferrer">いまからはじめるSvelte3</a><br><br>この本の中では、Svelteを使ってライフゲームを実装していくのですが、似たようなやり方でリバーシもできそうだなと思ったので実装してみました。<br></p><h2 id="h57d3da36fb">できあがったもの</h2><p><a href="https://svelte-reversi.netlify.app/" target="_blank" rel="noopener noreferrer">https://svelte-reversi.netlify.app/</a><br></p><h2 id="h88876ec3b5">リポジトリ</h2><p><a href="https://github.com/EringiV3/svelte-reversi" target="_blank" rel="noopener noreferrer">https://github.com/EringiV3/svelte-reversi</a><br></p><h2 id="h136f7ff154">実装の雰囲気</h2><p>ボード（マスの集合体）を状態と保持しておき、クリック操作によってボードの状態が更新され、最新のボードの状態がレンダリングされます。</p><pre><code>&lt;main&gt;
    &lt;div class="board"&gt;
        {#each board as row, i}
            {#each row as square, j}
                &lt;div
                    class="square"
                    class:white={square.color === 'White'}
                    class:black={square.color === 'Black'}
                    on:click={(e) =&gt; handleClick(i, j)}&gt;
                    {#if square.color}
                        {square.color === 'White' ? '○' : '●'}
                    {/if}
                &lt;/div&gt;
            {/each}
        {/each}
    &lt;/div&gt;
    &lt;div&gt;currentPlayer: {player.color}&lt;/div&gt;
    &lt;div&gt;
        {#if errorMessage !== null}{errorMessage}{/if}
    &lt;/div&gt;
    &lt;div&gt;
        {#if gameResult !== null}
            &lt;div&gt;{gameResult}&lt;/div&gt;
        {/if}
    &lt;/div&gt;
&lt;/main&gt;</code></pre><p><br></p><pre><code>    let board: Board;
    let player: Player;
    let errorMessage: string | null = null;
    let { boardStore, playerStore, gameResult } = initializeGame();
    boardStore.subscribe((value) =&gt; {
        board = value.board;
    });
    playerStore.subscribe((value) =&gt; {
        player = value;
    });


    function handleClick(i: number, j: number) {
        const position = { row: i, col: j };
        if (canPutStone(board, player.color, position)) {
            errorMessage = null;
            putStone(player.color, position);
            togglePlayer();


            const existsEmptySquare = !!board.find(
                (row) =&gt; row.find((square) =&gt; !square.isFilled) !== undefined
            );
            if (!existsEmptySquare) {
                let whiteStoneCount = 0;
                board.forEach((row) =&gt; {
                    whiteStoneCount += row.filter(
                        (square) =&gt; square.color === "White"
                    ).length;
                });
                const blackStoneCount =
                    ROW_SIZE * COLUMN_SIZE - whiteStoneCount;
                gameResult =
                    whiteStoneCount &gt; blackStoneCount
                        ? "Whiteの勝利です"
                        : "Blackの勝利です";
            }
        } else {
            errorMessage = "無効な一手です";
        }
    }</code></pre><p><br>既に.svelteファイルのscriptタグ内でのTypeScriptのサポートがされており、lang="ts"と記述すれば.svelteファイル内でTypeScriptが使えます。<br>ただ、自分が解決できなかった問題として、「.tsファイルからのimport」があります。<br>Storeの実装を別のファイルに切り出したかったのですが、reversi.tsファイルからのexportをApp.svelteでimportしようとするとエラーになってしまいました。.jsファイルなら問題ないのですが...。<br>Svelteはググって出てくる情報がまだそんなに多くないので、調べて解決することができませんでした。（rollupの設定ファイルの記述とかまったくわからない）<br>なので、App.svelteにStore含めたすべての実装を詰め込んであります。<br>今回作った機能少なめのリバーシ程度のアプリケーションだったらなんとかなりますが、これ以上規模が大きくなると、Storeの実装を外部ファイルに切り出して隠蔽できないというのは破綻まっしぐらだと思うのでなんとかしたいです（.jsファイルにすれば問題なかったけど型を使いたかったからその選択はしませんでした）。<br><br>また、.svelteファイルのscriptタグの中の記述量が増えていくのは、再利用性の点でよくないのでDOMに依存するコードだけ(今回ならhandleClick関数)を残しておき、あとは外部のtsファイルに切り出すのが良さそうです。<br>Storeに対する操作の詳細の隠蔽 + 再利用というのはReact(Hooks) + Recoilでの考え方と同じですね。<br>Storeの実装でなんのライブラリを使うかという悩みが発生しないのはStoreを内蔵しているSvelteのいいところだと個人的には思います。<br></p><h2 id="h8d78e14043">感想</h2><p>Reactを多少書ける自分が触った感じ、書き方で迷うことはそんなになかったし、全体的に直感的な記述ができるUIライブラリだなという感想です。<br>いまやReact, Vueと並んで比較されることも増えてきたライブラリなので、キャッチアップしておく価値はあると思いました。<br>公式のチュートリアルも丁寧なので、もっと採用例が増えて日本語の情報も増えてくれるのを期待します。</p>

Svelteを使ってリバーシを作ってみた

<p>はじめての転職活動が無事に終わったので、転職活動の流れや考えたことをまとめておこうと思います。<br></p><h2 id="h9519d41273"><strong>転職活動を始めたきっかけ</strong></h2><p>新卒で入社した今の会社で1年以上継続してアサインされていた受託案件がまだ続きそうで、リリース後も保守フェーズにアサインされることが予測でき、自分の身につけたいスキルと今の職場で身につけることのできるスキルセットが乖離していく一方だから、というのが転職活動を考え始めたきっかけです。<br>今の自分の興味はモダンフロントエンドにあります。<br>Twitterのフロントエンドエンジニアの方々はみんなVue/Reactをかいていて、フロントエンドエンジニアなのにサーバーサイドのテンプレートエンジン + Vanilla JSしか業務経験がないことに対して相当な焦りを感じており、仕事でレガシーフロントエンドを触り続けるのが日々苦痛に感じるようになってしまいました。<br>また受託の案件で、あまり意味を感じないドキュメントの作成に多くの時間を取られたり、ソースコードそのものの品質を上げるためのアクションを行うことなく、テストで品質を担保しようとする(人的リソースを投入して解決しようとする)姿勢が自分には合わないなと感じました。<br>他には、明らかに違和感のあるUIを「設計書通り」だからでそのまま放っておかなければいけないとか、エンジニアとして自分のやっていることに自信を持てなくなりそうな場面があったのもストレスを感じていた点です。<br>自分がエンジニアとして働いていく中で大切にしていきたい価値観として、「自分が作ったものに責任と自信を持って仕事をしたい」という思いがあります。<br>新卒エンジニアとして2年弱働いて、開発に対する自分の心持ちがある程度まとまってきた結果、今の会社のやり方では自分が楽しく働けないなと思いました。<br></p><h2 id="h37365b6e9b"><strong>転職活動の方法</strong></h2><p>Wantedlyと、転職エージェントを併用しました。<br>メインはWantedlyで、転職エージェントはwebに公開されてない求人を知るために使用していました。<br>Wantedlyで自分が働きたいと思える環境を提供してくれそうな企業に3社ほど応募しました。<br>転職エージェント経由では2社応募しました。<br>あとはGitHub Pagesに職務経歴を公開したり、この技術ブログをアウトプットの例としてWantedlyのプロフィールに載せたりしました。<br>この辺はエンジニアならやってる人多そうですね。他に特別なことはしてないです。<br></p><h2 id="h766fd7c0bd"><strong>転職活動の結果</strong></h2><p>Wantedlyで応募した2社から内定をいただき、以下の「会社を選ぶ上で重視したこと」によりマッチする会社に転職することとなりました。<br></p><h2 id="hc0309464e8"><strong>会社を選ぶ上でで重視したこと</strong></h2><p>以下を重視しました。</p><ul><li>事業に納得感が持てること</li><li>楽しく働けそうなこと</li></ul><p><br>新卒で入社した会社(現職)は、なんの技術もなかった学生時代にアパレルが好きだからという理由だけで選びました。<br>アパレルECに関するシステム全般をサービスとして提供している会社だったため、アパレルが好きだった自分にはとてもマッチしていたと思います。<br>実際に2年弱働いてみて、アパレルECに関する仕事に取り組むのはモチベーションの面ですごく良かったです。<br>入社当時は本当になんのスキルもありませんでしたが、アパレルブランドのECサイトを作れるというモチベーションのおかげで技術の勉強に熱意を持って取り組めました。<br>あと、自分の好きなブランドの開発に携われることもあったし、仕事のおかげで好きなブランドが増えたりもしました。<br>これは、アパレルが好きな自分が「事業」という観点を重視して就職先を選択したため得られた利点だと思います。<br>この経験から、自分が転職先を考える上で「事業への納得感」は重要だと考えました。<br><br>もうひとつ、自分が「楽しく働く」には以下の3点が重要だと思っています。</p><ul><li>自分が関わるプロダクトに自信と責任を持って開発できること</li><li>エンジニアとして求められる成果物のハードルが低すぎないこと</li><li>生活する上でそんなに我慢することなく暮らせるだけのお金がもらえること</li></ul><p><br></p><h3 id="hca444b658b"><strong>自分が関わるプロダクトに自信と責任を持って開発できること</strong></h3><p>受託開発であるあるなパターンではないかと思うのですが、個人的に嫌なのが「要件一覧・設計書に記載がないのでできません」とお客さんとの間に壁をつくってしまうパターンです。<br>契約の都合とかお金の話があると思うので仕方ないこともあると思うのですが、個人の感想としては、もっとお客さんと近い距離で仕事したいなと思います。<br>お客さんとの間に壁を作ってしまうと、「こうしたほうがもっとよくないですか？」みたいな提案もしにくくなるし、言った言ってないみたいな責任のなすりつけあいみたいになっていきます。<br>そんな状態でいいものが作れるとは思えないです。<br>簡単にまとめると、受託で言われた通りの機能をただ作るだけではなく、自分たちのプロダクトをエンジニアとして裁量をもって改善していけるような環境で働きたい、という感じです。<br>自分たちが開発しているものをより良くしていこうという気持ちで仕事ができれば、自分が手掛けたものに自信と責任を持つことができると考えています。<br></p><h3 id="h8bbf462715"><strong>エンジニアとして求められる生産性のハードルが低すぎないこと</strong></h3><p>設計書に書いてある機能を実装するだけ、ではなくその機能がどんな課題を解決するのか・なぜ求められているのかを理解した上で要件や仕様から考えて、実装して実現することのできるエンジニアになりたいです。<br>また、スモールチームで力を発揮できるようになりたくて、そういうエンジニアになるためには個人に求められる生産性が、自分の持つ能力でギリギリ実現できるかどうか、くらいの環境で働くことが必要だと思っています。<br></p><h3 id="h9e99a868f8"><strong>生活する上でそんなに我慢することなく暮らせるだけのお金がもらえること</strong></h3><p>立地がいい1LDK以上の家に住めて、ジムに通えて、たまに贅沢して良いメシが食べれて、節約とか考えなくてもよくて、好きな服をシーズンごとに買えて、年に数回は旅行に行けて、それでもちょっと余りそう、くらいのお金を貰えると嬉しいです。<br><br>次の職場はこの3つを満たしているので、とても楽しく働けそうです。<br></p><h2 id="h7b0a9a88e2"><strong>転職先での使用技術</strong></h2><p>ReactとTypeScriptでフロントエンドをやります。<br>業務ではレガシーフロントエンド(Laravel)の経験しかないので、仕事でモダンフロントエンドをやれるのはとても嬉しいです。<br>スモールチームなので、フロントエンドだけでなく、バックエンドをやる機会もありそうです。<br>現状フロントエンドの知識しかないので、バックエンドの知見も広めていきたいです。<br>あと、今年はせっかくAWS勉強してソリューションアーキテクトを取ったりしたのでそれも活かせればいいなと思います。<br></p><h2 id="hbec58bb6c5"><strong>今後のキャリアプラン</strong></h2><p>5年後までに、チームをリードできるエンジニアを目指します。<br>自分のことだけでなくチーム全体を俯瞰して見ることができて、チームの生産性を高めていくためのアクションを起こせるようになっていきたいです。<br>そのために、今はとにかく技術を磨くこと・品質の高いソフトウェアを作るために必要な知見を貯めることに集中する時期だと考えています。<br>10年後はまだ見えてないです。けどコードを書くことは続けていたいなとは思います。<br><br></p><h2 id="h8d78e14043">感想</h2><p>受託での大規模フロントエンドはマジで地獄だからできれば二度とやりたくないというのを書こうとしたらネガティブな文章で溢れてしまったので消しました。<br>年内に、自分が満足できる形で転職活動を終えることができてよかったです。年明けから自分が望む環境で働けると思うととてもワクワクします。<br>業務経験が浅くても、日々のアウトプットを継続していればそれを評価してくれる企業はきっとあります。<br>自分みたいに、何もスキルがない状態で1～2年エンジニアとして仕事をしてきて、そろそろ次のステップに…と考えている方の参考になれば幸いです。</p>

はじめての転職活動を終えて

ShopifyのStorefront APIを使用してNext.js製のECフロントを構築した

<p>Reactでスライダーを実装したので、実装方法を記録しておきます。<br>UIに関する実装は自分なりの得意な実装方法を持っておきたいなという気持ちがあります。<br>なので、今後もUIに関する実装方法は積極的にブログに残していきます。<br><br>今回はスライダーということでSwiperというライブラリを使用しました。<br><a href="https://swiperjs.com/" target="_blank" rel="noopener noreferrer">https://swiperjs.com/</a><br><br>Swiperは仕事でReactではない環境（Vanilla JS）で使用したことがあったのですが、Reactで使うのは初めてです。<br>調べてみるとReact Componentが提供されているようなので、それを使ってVanilla JSよりも更に簡単に動かせそうです（Reactだけでなく、VueとSvelteのコンポーネントも提供されているようです）。<br>以下は公式ドキュメントの最小サンプルです。</p><pre><code>// Import Swiper React components
import { Swiper, SwiperSlide } from 'swiper/react';

// Import Swiper styles
import 'swiper/swiper.scss';

export default () =&gt; {
  return (
    &lt;Swiper
      spaceBetween={50}
      slidesPerView={3}
      onSlideChange={() =&gt; console.log('slide change')}
      onSwiper={(swiper) =&gt; console.log(swiper)}
    &gt;
      &lt;SwiperSlide&gt;Slide 1&lt;/SwiperSlide&gt;
      &lt;SwiperSlide&gt;Slide 2&lt;/SwiperSlide&gt;
      &lt;SwiperSlide&gt;Slide 3&lt;/SwiperSlide&gt;
      &lt;SwiperSlide&gt;Slide 4&lt;/SwiperSlide&gt;
      ...
    &lt;/Swiper&gt;
  );
};</code></pre><p><br>スライダーのスタイルもSassで提供されているので、<code>import 'swiper/swiper.scss'</code>で読み込みます。<br>Swiperコンポーネントにスライダーの挙動や見た目に関するオプションを指定できます。<br>SwiperSlideコンポーネントにスライダー要素の実態を埋め込んでおきます。<br>これだけで動くスライダーができて大変お手軽です。<br></p><h2 id="hc57404ac77">実際に使ってみる</h2><p>今回は、ECサイトにありがちな、スライダーの下にサムネイル画像の一覧があり、サムネイル画像をクリックするとスライダー要素も連動して動くものを実装します。<br>こんなコンポーネントになりました（Next.jsでの実装です）。<br><br>SwiperコンポーネントのonSwiperでSwiperインスタンスを受け取ることができるのでそれをstateに持ちます。<br>Swiperインスタンスが持っているプロパティはとても多く、以下のページにプロパティとメソッドの一覧があります。<br><a href="https://swiperjs.com/api/#methods" target="_blank" rel="noopener noreferrer">https://swiperjs.com/api/#methods</a><br><br>mapのindexをslideTo関数の引数に受け取り、SwiperインスタンスのslideToメソッドを呼び出すことでクリックされたスライド要素へのスライドを実現しています。<br></p><pre><code>import { useState } from 'react';
import { Product } from '@/types';
import Image from 'next/image';
import { Swiper, SwiperSlide } from 'swiper/react';
import SwiperCore, { Navigation, Pagination } from 'swiper';

SwiperCore.use([Navigation, Pagination]);

type Props = {
  product: Product;
};

const ProductImages: React.FC&lt;Props&gt; = ({ product }) =&gt; {
  const [swiperInstance, setSwiperInstance] = useState&lt;SwiperCore | null&gt;(null);
  const slideTo = (index: number) =&gt; {
    if (!swiperInstance) return;
    swiperInstance.slideTo(index);
  };
  return (
    &lt;&gt;
      {/* スライダー本体 */}
      &lt;Swiper
        spaceBetween={50}
        slidesPerView={1}
        navigation
        pagination={{ clickable: true }}
        onSwiper={(swiper) =&gt; setSwiperInstance(swiper)}
      &gt;
        {product.images.map((image) =&gt; {
          return (
            &lt;SwiperSlide key={image.id}&gt;
              &lt;Image
                src={image.src}
                alt={product.title}
                width={500}
                height={500}
              /&gt;
            &lt;/SwiperSlide&gt;
          );
        })}
      &lt;/Swiper&gt;

       {/* サムネイル画像一覧 */}
      {product.images.map((image, index) =&gt; {
        return (
          &lt;Image
            onClick={() =&gt; slideTo(index)}
            key={image.id}
            src={image.src}
            alt={product.title}
            width={100}
            height={100}
          /&gt;
        );
      })}
    &lt;/&gt;
  );
};


export default ProductImages;</code></pre><p><br>これでできるスライダーはこんな感じです。サムネイル画像（3種類のおにぎりの画像）をクリックするとスライダーもクリックされたサムネイル画像要素までスライドされます。<br><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/415dc12dde5243ff175c1ebb266024d7/25a48041a81848a543b5aeb8efdf3607.png" alt=""><br><br>Swiperは他にもページネーションをカスタマイズできたり、アニメーションをつけることができたり、イベントリスナを設定できたりと、とにかく用意されているAPIの量がとても多いのでスライダーに関する大体のことはできそうだなという印象のライブラリです。かつ、APIもシンプルでわかりやすいと思います。<br>React以外（VueやSvelete）でも使用することができるので学習コストも無駄にはならなそうです。<br><br></p>

Reactでのスライダー（カルーセル）の実装

<p>Next.jsをTypeScriptで使用するときのテンプレートを作りました。<br><a href="https://github.com/EringiV3/nextjs-with-typescript-template" target="_blank" rel="noopener noreferrer">nextjs-with-typescript-template</a><br><br>Reactを使った素振りでなにか作るときにNext.jsで始めるということが今後増えていきそうという理由で作った、よく使いそうなツールをまとめた自分用のテンプレートです。<br></p><h2 id="hcb7debd359">型チェック</h2><p>tscで型チェックを行います。<br>設定のベースは、<code>create-next-app</code>の<code>with-typescript</code>テンプレートです。一部理解できていないオプションもあります。</p><pre><code>  // tsconfig.json
  {
  	  "compilerOptions": {
  	    "allowJs": true,
  	    "alwaysStrict": true,
  	    "esModuleInterop": true,
  	    "forceConsistentCasingInFileNames": true,
  	    "isolatedModules": true,
  	    "jsx": "preserve",
  	    "lib": ["dom", "es2017"],
  	    "module": "esnext",
  	    "moduleResolution": "node",
	    "noEmit": true,
	    "noFallthroughCasesInSwitch": true,
	    "noUnusedLocals": true,
	    "noUnusedParameters": true,
	    "resolveJsonModule": true,
	    "skipLibCheck": true,
	    "strict": true,
	    "target": "esnext"
	  },
	  "exclude": ["node_modules"],
	  "include": ["**/*.ts", "**/*.tsx"]
}</code></pre><h3 id="h55f399465c">上記のオプションについて</h3><h4 id="hb039bf5c37">allowJs</h4><p>ts, tsxファイル以外のimportの許容。</p><h4 id="hd47cceef11"><br>alwaysStrict</h4><p>各ファイルへ"use strict"をつけて出力することを保証する。出力されたJSファイルはECMAScriptのStrictモードで実行される。<br>Strictモードについては以下を参照。<br><a href="https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Strict_mode" target="_blank" rel="noopener noreferrer">https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Strict_mode</a></p><h4 id="h3409ec6782"><br>forceConsistentCasingInFileNames</h4><p>ファイル名の大文字小文字を区別する。</p><h4 id="h41e78fccb6"><br>jsx</h4><p>jsx構文がどのようにファイルに出力されるかを制御するオプション。preserve, react, react-nativeがありpreserveではJSXを変更することなく.jsxファイルを出力する。</p><h4 id="h2429723d62"><br>lib</h4><p>コンパイルする際に使用する組み込みのJS API型定義や、ブラウザ上で使用されるAPIの型定義のライブラリを指定する。</p><h4 id="h569853fc43"><br>module</h4><p>出力されるJSのモジュールの形式を指定する。CommonJS形式（exports.<em>*</em>）かESModules（export ***)かを指定。</p><h4 id="h013bb79419"><br>noEmit</h4><p>JavaScript ソースコード、ソースマップ、型定義のファイルを出力しないようにします。型チェック機能だけを使用する場合にtrueにする。Next.jsはtscを使わずに内部でBabelでコンパイルしているらしい。</p><h4 id="h81f34f443a"><br>noFallthroughCasesInSwitch</h4><p>switch 文において、次の case へ処理を持ち越した場合にエラーを報告する。 switch 文内の空でない case 句が、<code>break</code>または<code>return</code>を含むことを確約する。</p><h4 id="h3f05325621"><br>noUnusedLocals&nbsp;</h4><p>利用されていないローカル変数について、エラーを報告する。</p><h4 id="h073eff5af4"><br>noUnusedParameters</h4><p>利用されていない関数のパラメータについて、エラーを報告する。</p><h4 id="h1d3b2652d5"><br>resolveJsonModule</h4><p>.json拡張子のファイルをモジュールとしてimportできるようにする。</p><h4 id="h4d18de3828"><br>skipLibCheck</h4><p>型定義ファイルのチェックをスキップすることで、コンパイル実行時間を短縮する。</p><h4 id="h60a8fab09d"><br>strict</h4><p>プログラムの正しさを強く保証するための幅広い型チェックの挙動を有効化する。<code>strictBindCallApply, strictFunctionTypes, strictNullChecks, strictPropertyInitialization</code>オプションの有効化と等価。</p><h4 id="he608e7281d"><br>target</h4><p>出力されるJSのバージョンの指定。<br></p><h3 id="h3daed9a170">理解できていないオプション</h3><ul><li>isolatedModules</li><li>moduleResolution</li><li>esModuleInterop</li></ul><p><br></p><h2 id="h16cfc26709">linter, formatter</h2><p>ESLint + Prettierの構成です。</p><pre><code>// .eslintrc.json
{
	  "parser": "@typescript-eslint/parser",
	  "extends": [
	    "plugin:@typescript-eslint/recommended",
	    "plugin:react/recommended",
	    "plugin:prettier/recommended",
	    "plugin:prettier/react",
	    "plugin:prettier/@typescript-eslint"
	  ],
	  "plugins": ["@typescript-eslint", "react", "prettier"],
	  "rules": {
	    "react/react-in-jsx-scope": "off"
	  },
	  "globals": {
	    "React": "writable"
	  }
}</code></pre><h3 id="hc4b37ec9fa">上記の設定について</h3><h4 id="h4d3db041c2">parser</h4><p>ESLintがTypeScriptをパースできるようにするためのパーサの指定。</p><h4 id="h39efb78aba"><br>extends</h4><p>pluginによって提供されるルールを使用することによって設定を拡張するという理解。「plugin:{プラグイン名}/{設定名}」という形で指定する。<br></p><ul><li><strong>plugin:@typescript-eslint/recommended</strong></li></ul><p>			TypeScript用のESLintルール<br><br></p><ul><li><strong>plugin:react/recommended</strong></li></ul><p>			React用のESLintルール<br><br></p><ul><li><strong>plugin:prettier/recommended</strong></li></ul><p>			ESLintとPrettierを共存させるためのルール。ESLintのフォーマットに関する設定を全てOFFにし、フォーマットに関してはESLintの中からPrettierにすべて任せる<br><br></p><ul><li><strong>plugin:prettier/react</strong></li></ul><p>			eslint-plugin-reactのフォーマットに関するルールをOFFにする。<br><br></p><ul><li><strong>plugin:prettier/@typescript-eslint</strong></li></ul><p>			競合するESLintのルールを無効化する。最後に書く必要があるっぽい。</p><h4 id="h189bb9ce89"><br>plugins</h4><p>eslint-plugin-xxxのxxxの部分を指定する（eslint-plugin-は省略可能なため）。xxxに関する設定の塊みたいな認識。</p><ul><li>@typescript-eslint</li><li>react</li><li>prettier</li></ul><h4 id="h4fe0a49a06"><br>rules</h4><p>特定のルール（最小単位）のON/OFFを切り替える。</p><ul><li><strong>react/react-in-jsx-scope</strong></li></ul><p>			Next.jsでは各jsx/tsxファイル内でReactをimportする必要がないので、OFFにする。</p><h4 id="h1955b7641d"><br>globals</h4><p>実行時に追加するグローバル変数の追加の指定。writableを指定することで変数に対しての書き込みも可能になる。</p><ul><li><strong>React</strong></li></ul><p>			Next.jsでは各jsx/tsxファイルでReactをimportしないため。<br><br><br>フォーマットに関する設定は.prettierrcに書く。</p><pre><code>// .prettierrc
{
	  "semi": true,
	  "singleQuote": true
}</code></pre><p><br></p><h2 id="h63ad3943f9">テスト</h2><p>jestでユニットテストを実行します。</p><pre><code>// jest.config.js
module.exports = {
	  roots: ['&lt;rootDir&gt;/src'],
	  testMatch: [
	    '**/__tests__/**/*.+(ts|tsx|js)',
	    '**/?(*.)+(spec|test).+(ts|tsx|js)',
	  ],
	  transform: {
	    '^.+\\.(ts|tsx)$': 'ts-jest',
	  },
	};</code></pre><p><br>今回作ったテンプレートでは「<strong>tests</strong>」というディレクトリを作って、その中に「xxx.test.ts」のようなファイルを作って<code>yarn test</code>でテストを実行するようにしています。<br></p><h2 id="h193252ff15">precommit</h2><p>huskyを使用して、precommitのhookで型チェック・lint・テストを回しています。<br>規約を破るソースコードはpushさせないという思想です。<br></p><h2 id="hfdbb292dd3">テンプレートを作ってみた感想</h2><ul><li>設定が多い。とはいえ、Next.jsがBabelやwebpackの設定を隠蔽してくれているので楽な方なんだと思う。</li><li>ESLintは特に複雑に感じる。ただ、今回テンプレートを作ってみたことでESLintへの理解度は上がった。</li><li>大変だけど、最初にこのへんの設定をセットアップしておけば後から設定の中身を変更することは大変じゃないのでテンプレートを作った価値はあった。特にリントツールは初期に導入を済ませておくことに価値があるはず。</li><li>このテンプレートを使ってNext.jsの素振り頑張る。</li></ul><p><br></p>

Next.jsのTypeScriptテンプレートを作った

<h2 id="h9707d3a59a">概要</h2><p>ブログに動的OGP生成機能を追加しました。<br>そのために、初めて自分でnpmパッケージを開発して公開しました。<br><a href="https://www.npmjs.com/package/node-ogp-creator" target="_blank" rel="noopener noreferrer">node-ogp-creator</a><br><a href="https://github.com/EringiV3/node-ogp-creator" target="_blank" rel="noopener noreferrer">リポジトリ</a><br><br>node-ogp-creatorを使用すると以下のようなOGP画像を動的に生成することができます。<br><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/3af8d2430297287f2f840c005af884cd/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202020-10-19%2022.58.39.png" alt=""><br><br>node-ogp-creatorでは、canvasに文字列を描画してpngに出力しています。<br>使用方法は以下のような感じです。</p><pre><code>// gatsby-node/index.ts  
blogResult.data.allMicrocmsBlog.edges.forEach(({ node, next, previous }) =&gt; {
    createOGP({
      title: node.title || "",
      path: `public/ogp/${node.slug}.png`,
      userName: TWITTER_ACCOUNT || "",
      width: 640,
      height: 480,
      fontPath: "fonts/NotoSansCJKjp-Regular.otf",
      styles: {
        font: "Noto Sans CJK JP",
        fontSize: 30,
      },
    })
    createPage({
      path: `/blog/post/${node.slug}`,
      component: path.resolve(`./src/templates/blogPostTemplate.tsx`),
      context: {
        id: node.id,
        next,
        previous,
      },
    })
  })</code></pre><p><br></p><h2 id="h96946ab337">もう少し詳細</h2><ul><li>tiny-segmenterというライブラリを使用して、タイトル文字列の形態素解析を行い、不自然な位置での改行を避けるようにしています</li><li>全角文字列は2文字、半角文字列は1文字としてカウントし、文字列幅の調整をいい感じにやっています</li><li>フォントファイルの指定をできるようにしているのは、デフォルトだと日本語が文字化けするためです</li><li>背景に画像を設定することは現状はできません。気が向いたら対応するかもしれないです</li></ul><p><br></p><h2 id="h1331c56b22">作ってみた感想</h2><p>まず、人生初npm publishできたのが嬉しかったです。<br>公開して実際に自分でyarn addして使ってみたら文字化けしまくりで使い物にならなかったときはショックでしたが。<br>タイトルの座標計算が結構しんどくて、世の中の自作OGP画像生成コード作っている人たちはすごいなと思いました。<br>Node.js + TypeScriptにも慣れてきました。今回のライブラリ開発では初めてJestを使ってテストコードも書きました。<br>ツール周りの理解（prettier, ESLint, babelなど）が浅いのでどこかのタイミングでちゃんと時間撮って勉強したいです。<br><br>SNSシェアボタンの追加、動的OGP生成、シンタックスハイライト（jsxのハイライト壊れる問題はprismjs → hightlight.jsに乗り換えることで解決しました）が揃ったことで、自作技術ブログに必要な機能は大体揃ってきたかな、という印象です。TypeScript化もすでに終わったので、ブログへの機能追加は一旦このへんで落ち着いておこうかなと思います。余裕があったら目次リンク対応とかやりたいです。</p>

ブログに動的OGP生成機能を追加しました

<p>Typescript + Node.jsの素振りとして、「BacklogとJiraのdiffをとってJSONに吐き出す」スクリプトを作りました。<br><a style="color:#6b46c1" href="https://github.com/EringiV3/backlog-jira-diff" target="_blank" rel="noopener noreferrer">backlog-jira-diff</a><br><br>作ろうと思った背景としては以下です。完全に自分用です。</p><ul><li>BacklogとJiraの両方を使用していて二重管理になっている</li><li>Jiraのチケットを完了にしたのに紐づくBacklogの課題を完了にしわすれてしまう</li></ul><p><br>Backlogで未完了の課題のIssueKeyをJiraチケットのタイトル or 説明欄に含めるというルールで運用されているという前提です。<br><br>Backlog APIとJira APIについては、クライアントライブラリがあったのでAPI呼び出し部分を自分で実装することなく楽ができました。</p><ul><li><a style="color:#6b46c1" href="https://github.com/jira-node/node-jira-client" target="_blank" rel="noopener noreferrer">node-jira-client</a></li><li><a style="color:#6b46c1" href="https://github.com/nulab/backlog-js" target="_blank" rel="noopener noreferrer">backlog-js</a></li></ul><p><br>Gatsby.jsのTypescript化をしたので、Node.js環境でのTypeScriptを書いた経験は一応あるのですが、ノンフレームワークな素のNode.js + TypeScriptは初めてだったので詰まったところを記録しておきます。<br>というか振り返ってみたらそもそもNode.jsすらロクに書いたことがなかった。</p><h3 id="h9bb32e62a5">dotenvの環境変数読み込み</h3><p>.envファイルから環境変数を読み込むためにdotenvをimportして使用することは一般的だと思います。ただ、コードの位置によってprocess.envから取得できたりできなかったりしました。<br>原因は、dotenv.config()の実行位置でした。config()実行時に.envから環境変数を取得してprocess.envに反映してくれるようです。<br>import直後にconfig()を実行するようにしたら、process.envからundefinedではなくちゃんと設定した期待通りの値が帰ってくるようになりました。</p><pre><code> import dotenv from "dotenv";
  dotenv.config();  </code></pre><h3 id="ha8c3590148">Promise.all()の使い所</h3><p>Promiseについては、<a style="color:#6b46c1" href="https://azu.github.io/promises-book/#introduction" target="_blank" rel="noopener noreferrer">JavaScript Promiseの本</a>で学習しました。<br>概念はなんとなく覚えていたのですが、具体的な使用場面が想像できないままで使った経験もありませんでした。<br>ただ、今回はBacklogの課題一覧取得のAPIの制約（取得上限が100件）により、プロジェクトごとに別々のAPI呼び出しが必要だと考え、Promise.allを使ってみました。</p><pre><code> const undoneTickets: BacklogGetIssuesResponse[][] = await Promise.all(
      this.targetProjectIds.map(
        async (projectId) =&gt;
          (await this.client.getIssues({
            projectId: [projectId],
            keyword: "",
            statusId: this.undoneStatusIds,
            count: 100,
          })) as BacklogGetIssuesResponse[]
      )
    );
  </code></pre><p>mapでPromiseの配列を受け取りそれらがすべてresolveされるまで待つ、というのがちゃんと理解できました。<br></p><h3 id="hdf634c6c70">ライブラリからimportするときによくみる「@」</h3><p>import時のpathの指定を相対パスではなく、絶対パスで書くための記法。必ずしも@から始まる必要はないが@がスタンダードっぽい。<br>tsconfig.jsonのpathsの指定で設定できる。</p><pre><code> // tsconfig.json
    "baseUrl": "./",
    "paths": {
      "@types": ["./src/types"]
    }

    // importする側
    import { SearchJiraResponse, DoneJiraTicket } from "@types";
  </code></pre>

Typescript + Node.jsの練習

<p>microCMSには、ステータスが「下書き中」になっている記事を取得できる機能が用意されています。<br>今回は、その機能を利用してブログのプレビューページを作りました。<br></p><h2 id="hac84e4e38d">モチベーション</h2><ul><li>執筆中の記事の見栄えを公開前に確認したい</li><li>このブログはJamstackな構成でできているので、記事公開 → デプロイ → ページ生成 されるまで実際の表示が確認できず、リスキー</li><li>デプロイすることなくプレビュー可能な仕組みが必要</li></ul><p><br></p><h2 id="h47d2486890">大まかな方針</h2><p>プレビュー用のページをGatsbyのsrc/pages配下に用意しておき、クエリパラメータで指定されたcontentId, draftIdに一致するコンテンツをmicroCMSからクライアントサイドで取得します。<br>取得した記事のデータをReact コンポーネントに渡してクライアントサイドでレンダリングします。<br></p><h2 id="h31d727ccda">準備</h2><p>microCMSの管理画面から、プレビューボタン押下時の遷移先URLを設定しておきます。<br><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/e78223554c28f01be016f9d2207fc8cf/6ca0c36044fe9183e259e861dbf6dee8.png" alt=""><br>上記画像のblogPostPreviewにあたる文字列が、Gatsbyのプレビュー用ページのファイル名と一致することになります。<br><br>クエリパラメータからcontentIdとdraftIdを取得する必要があるため、クエリパラメータから値を取得するためのパッケージを追加しておきます。<br><code>yarn add gatsby-query-params</code></p><h2 id="h922edff87b">実装</h2><h3 id="h2fd565797a">プレビューページの追加</h3><p>src/pages配下にblogPostPreview.jsというページファイルを追加しました。今回は、ブログ投稿専用のプレビューページであることを明示したかったのでこのようなファイル名にしました。<br></p><h3 id="h2ea49f6295">下書き状態のコンテンツを取得する</h3><p><code>gatsby-query-params</code>から<code>getSearchParams</code>をimportし、contentId, draftIdを取得します。<br>contentId, draftIdを使って、下書き状態のコンテンツを取得するためのクエリを組み立ててfetchします。</p><pre><code>const { contentId, draftKey } = getSearchParams()
    const [postData, setPostData] = useState(null)
  
    useEffect(() =&gt; {
      if (!contentId || !draftKey) return
      fetch(
        `https://xxxxxxxxxxxxxxx.microcms.io/api/v1/blog/${contentId}?draftKey=${draftKey}`,
        {
          headers: {
            "X-API-KEY": "xxxxxxxxxxxxxxxxxxxxxxxx",
          },
        }
      )
        .then(response =&gt; {
          if (response.ok) {
            return response.json()
          }
        })
        .then(json =&gt; {
          if (json) {
            setPostData(json)
          }
        })
    }, [contentId, draftKey])</code></pre><p>APIキーがむき出しになってしまいますが、個人開発の用途であること・とりあえず早くプレビュー機能を使える状態にしたかったためこのままでいきます。<br>getの操作でした使用されないAPIキーなので、フロントエンドで見える状態になっていても特に問題ないかなと思います。<br>気になる方は、microCMSの公式ブログにNetlify Functionsを使ってサーバサイドで下書き状態の記事のデータを取得する実装が紹介されているのでこちらを参考にすると良さそうです。<br>Nuxt.jsでの実装例が掲載されてますが、使っているフレームワークによらず参考にできそうな実装です。<br><a style="color:#6b46c1" href="https://microcms.io/blog/nuxt-jamstack-preview" target="_blank" rel="noopener noreferrer">microCMSとNuxtでプレビュー画面を作成する</a></p><h3 id="h5e13b1fe61">レンダリング</h3><p>データが取得できたらもう殆ど完成です。最後は記事詳細ページですでに使用されているPostHeader, PostBodyコンポーネントに記事のデータをpropsで渡してあげるだけです。<br>ここまでの作業でできたファイルは以下となります。（jsx のsyntax highlightが壊れてる問題がまだ解決できてなくてめちゃくちゃ不便）<br><a style="color:#6b46c1" href="https://github.com/EringiV3/devBlog/blob/master/src/pages/blogPostPreview.js" target="_blank" rel="noopener noreferrer">https://github.com/EringiV3/devBlog/blob/master/src/pages/blogPostPreview.js</a><br><br>記事の公開日時のデータについて、SSGするときはgraphqlのクエリでフォーマット指定してリクエストを行っているため自分で公開日時のフォーマットは行っていません。<br>ただ、プレビューではgraphqlは使わずにfetchで取得しているのでフォーマットの指定はできません。そのためフォーマットされていないプレーンな状態の日時文字列をそのまま表示しています。<br>（プレビューだから対応する気が起きなかった）<br><br><br><br>以上でプレビュー機能の実装が一通り完了したので、microCMSのプレビューボタンを押してみてプレビューができてるかを確認します。<br><br>「画面プレビュー」ボタンを押して...<br><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/3bf14804775feb649718a3b95f382900/f2a40858f338aed1cae5facea463598b.png" alt=""><br>プレビューページ用のURLで下書き状態の記事のプレビューができました！！<br>これで完成です！<br></p><h2 id="ha214098e44">まとめ</h2><p>microCMSのプレビュー画面機能を使用して、Gatsby上に動的なプレビューページを作りました。<br>プレビュー機能はブログには必須と言えるレベルの機能だと思うので、自作ブログを構築して早い段階で用意できて安心です。</p>

Gatsby で microCMSのプレビュー機能対応

<p>エンジニア歴2年目に突入し、もう半年ほど経ちそうです。<br>最近になって、本業では使わない（使えない）技術スタックを身につけるためにプライベートの時間を使って勉強する習慣がついてきました。<br>が、やはり仕事で使わないとすぐ頭から抜けてしまうので、理解したことを記録しておくためにこのブログを作ることにしました。<br>あと自作ブログをやってみたかったというのも理由としてはあります。</p><h3 id="h7d0aeafefc">筆者のスキルセット</h3><ul><li>まともに書ける言語の中ではPHP歴が一番長い（7系しか書いたことないです。仕事ではPHP7.4使ってます）</li><li>CSSは最低限かける。複雑なアニメーションとかは厳しい。</li><li>jsは仕事ではノンフレームワークなvalilla jsでしか書いたことない</li><li>Reactは独学で初めて2~3ヶ月くらい</li></ul><p><br>自分のスキルセットはこんな感じです。<br>このレベル感の人間がGatsbyで自作ブログ構築するにあたって、学習の流れや難しかったところ・ハマったところ等を書こうと思います。</p><h3 id="hcdab8eedf6">学習の流れ</h3><p>Gatsby.jsは、ページの表示に必要なデータをGraphqlで一気に取得して、それをReactコンポーネントに流し込むことでSSG(ServerSideGenarating)してくれる静的サイトジェネレータです（という理解です）。<br>そのため、GraphqlとReactの理解は必須となります。<br><br>GraphqlはUdemyで1本講座を買って勉強しました。この方の動画はTypeScript入門で買ったことがあるのですが、わかりやすかったです。<br><a style="color:#6b46c1" href="https://www.udemy.com/course/graphql-with-react/" target="_blank" rel="noopener noreferrer">フロントエンドエンジニアのためのGraphQL with React 入門</a><br><br>その後に、「Webサイト高速化のための静的サイトジェネレーター活用入門」という本を読みました。Gatsby本とか呼ばれてるらしいです（？）<br>この本を手を動かしながらやりきると、Gatsby + Contentful製のブログが一本出来上がります。<br>このブログもそれをベースにカスタマイズして作りました。<br>ページネーションやSEOの実装まで丁寧に解説してくれています。<br><a style="color:#6b46c1" href="https://www.amazon.co.jp/%E3%80%90%E7%89%B9%E5%85%B8%E4%BB%98%E3%81%8D-%E3%80%91Web%E3%82%B5%E3%82%A4%E3%83%88%E9%AB%98%E9%80%9F%E5%8C%96%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE-%E9%9D%99%E7%9A%84%E3%82%B5%E3%82%A4%E3%83%88%E3%82%B8%E3%82%A7%E3%83%8D%E3%83%AC%E3%83%BC%E3%82%BF%E3%83%BC%E6%B4%BB%E7%94%A8%E5%85%A5%E9%96%80-Compass-Books%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA/dp/4839973008" target="_blank" rel="noopener noreferrer">Webサイト高速化のための静的サイトジェネレーター活用入門</a><br><br>Reactそのものに関しては、話すとボリュームが大きくなりそうなので省略します。</p><h3 id="h8c1ceaa430">Gatsby + microCMSでのブログ実装</h3><p>実現する機能としては以下のような感じです。</p><ul><li>コンテンツはすべてmicroCMSで管理</li><li>シンタックスハイライト</li><li>記事のカテゴライズ</li></ul><p><br>まずは、Gatsby本をやってできたブログから、Contentful依存の実装を剥がすしてmicroCMSでの実装に置き換えるところからはじめました。<br>microCMSを選んだのは、管理画面が日本語でUIもContentfulよりわかりやすいと感じたからです。<br>Gatsby本ではContentful依存の実装の剥がし方・microCMSへの乗り換え方まで付録で解説しくれていたのでこのステップでは特に困りませんでした。</p><h3 id="h610e988ca2">microCMSで用意するAPI</h3><p>ブログAPI、カテゴリAPI、aboutページ用APIを用意しました。<br>gatsby-source-microcms という、gatsbyでmicroCMSからGraphqlでデータ取得できるようにするためのプラグインが用意されているのでこちらにAPIの設定を記載します。</p><pre><code>
        // gatsby-config.js
        {
            resolve: "gatsby-source-microcms",
            options: {
              apiKey: process.env.microCMS_API_KEY,
              serviceId: "eringiv3devblog",
              apis: [
                {
                  endpoint: "blog",
                  query: {
                    limit: 100,
                  },
                },
                {
                  endpoint: "category",
                  query: {
                    limit: 100,
                  },
                },
                {
                  endpoint: "about",
                  format: "object",
                },
              ],
            },
        },
   </code></pre><p>リスト形式のレスポンスか、オブジェクト形式のレスポンスを返すかで、formatオプションの値を変える必要がある点に注意が必要です。<br>ドキュメントにきちんと記載されているのですが、見落としてしまいハマりました。<br>デフォルトでは、<code>format: "list"</code>が指定されるようで、オブジェクト形式のレスポンスを返すAPIで明示的に<code>format: "object"</code>を指定しないとビルドが失敗します。</p><h3 id="h5ead4ef981">コードにシンタックスハイライトを効かせる</h3><p>「Gatsby syntax highlight」とかでググっても、gatsby-remark-prismjsというプラグインを使ってmarkdownで入稿する前提でハイライトを効かせる方法ばかりヒットします。<br>「静的サイトジェネレータを使って技術ブログを開設する」という目的に対しては多くの場合、ContentfulやmicroCMSのようなヘッドレスCMSを使わなくても、markdownファイルにコンテンツを書き込んでgit pushすれば済む話なので、そもそもAPIのレスポンスの中に含まれるHTML文字列からシンタックスハイライトを効かせられるようにするというモチベーションが発生しないのだと思います。<br>ただ、今回はどうしてもmicroCMSを使ってみたかったのでmarkdownは使わずに済む方法を考えました。<br><br>レスポンスのHTML文字列からシンタックスハイライトを効かせる手順は以下のようにしました。</p><ol><li>microCMSの繰返し項目機能を使って、ブログコンテンツに繰返し項目（リッチエディタ項目 or HTML項目を設定）をもたせる</li><li>レスポンスに含まれる繰返し項目の項目IDで何の項目かを判別し、HTML項目の場合はHTMLとしてパースしReactコンポーネントに変換する</li><li>Prismjsを使って、useEffectでクライアント側でハイライトを行う</li></ol><p><br>コードはこんな感じになりました。<br><a style="color:#6b46c1" href="https://github.com/EringiV3/devBlog/blob/master/src/components/post-body.js" target="_blank" rel="noopener noreferrer">https://github.com/EringiV3/devBlog/blob/master/src/components/post-body.js</a><br><br>繰返し項目にHTML入力用の項目を設ける理由は、prismjsに言語の種類を識別させてハイライトして貰う必要があるためです。pre要素のclassに<code>language-xxx</code>を指定すると、xxx言語の構文として解釈してくれます。<br>ただ、問題点があってprismjsとjsxの相性が良くないみたいで自分の手元ではjsxのシンタックスハイライトを効かせることができていません。すぐには解決できなそうだったので今後の課題です。<br><br>繰返し項目のIDで処理を分岐させるのは、microCMSのブログに実装例があったのでそれを真似しました。<br><a style="color:#6b46c1" href="https://microcms.io/blog/update-repeater-field" target="_blank" rel="noopener noreferrer">繰り返しフィールドが追加されました</a></p><h3 id="hcc1af24286">スタイリング</h3><p>Gatsby本では外部のcssファイルにクラス指定でスタイルを当てていましたが、それをやめてstyled jsxを使ってみることにしました。CSS in JSのライブラリは種類が多くてどれを選択すればいいか迷ったのですが、グローバルな領域にスタイルを書き込んでいくのはどうしても嫌・styledComponentはコンポーネントが増えてなんか嫌という理由でstyled jsxを選びました。軽量かつ、<code>&lt;style jsx&gt;&lt;/style&gt;</code>で囲むだけでコンポーネントに対してscopedなスタイルを当てることができてシンプルなのがいいなと思いました。記法も普通のCSSと同じなのでとっつきやすかったです。<br>基本的にはすべてscopedにして、ページネーション等の複数のjsxファイルにまたがるクラスに対してのスタイルは<code>&lt;style jsx global&gt;&lt;/style&gt;</code>でグローバルな領域のスタイルとして記述しました。<br></p><h3 id="h9dcc071ccd">デプロイ</h3><p>Netlifyを使っています。GitHub, microCMSと連携してmasterへのコミットや、CMSで管理されているコンテンツの更新でデプロイされます。<br></p><h3 id="ha739b3b8f6">その他</h3><p>Google Analyticsやサイトマップの設定も、プラグインが用意されており、gatsby-config.jsにちょこっと設定を書き足すだけだったので自分でやることはほぼありませんでした。<br></p><h3 id="h4ddd7d9be8">計測</h3><p>トップページをLighthouseで計測してみたら4項目すべて100点でした！<br><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/eed9428f979e15fcda16f05bc5af5273/lighthouse.png" alt=""><br><span style="color:#2d3748">まだ1記事しか存在していないのでいい点数が出やすいのは当然だと思うので、今後記事が増えても点数が下がらないように気をつけます。</span><br><span style="color:#2d3748">ちなみに、記事詳細ページで計測したらもう少し低いスコアになりました。</span><br><img src="https://images.microcms-assets.io/assets/702dbaa8dfa34d1195fd2644792b2156/2185222d9e6ab3bc2e1f56b7890125e9/lighthouse_blogpost.png" alt=""></p><h3 id="ha214098e44">まとめ</h3><p>Gatsby + microCMSという構成で、コンテンツはすべてmicroCMS管理かつシンタックスハイライトも効かせられる最低限の技術ブログができました。<br>今後の改善点として以下があります。</p><ul><li>シンタックスハイライトについて、現在はクライアントサイドで実行するようになっているがGatsbyのメリットを活かせていない気がするので、サーバーサイドでハイライトした状態のHTML文字列を返すようにしたい</li><li>TypeScript導入</li><li>microCMSのプレビュー機能対応</li></ul><p><br>TypeScriptはできれば最初から入れたかったのですが、初めて触るフレームワーク（Gatsby）、初めて触るCMS（microCMS）という構成だったので、カオスになるのを防ぐために、とても使いこなせるとは言えないレベルの習熟度のTypeScriptを入れるのは先送りとしました。<br>とりあえず公開するところまでたどり着けたのは「Webサイト高速化のための静的サイトジェネレータ活用入門」とmicroCMSの運営の方（Twitterでつまづいているところをつぶやいたら助けてくれた！）のおかげだと思います。<br>アウトプットのために作ったブログなのでこれで満足しないようにしたいです。</p>