<p>仕事でReact Testing Libraryでコンポーネントテストをよく書くので、趣味の個人開発品でも導入してみることにしてみました。<br><br>調べてみると、今年8月にNext.js公式DocsにTestingが追加されているではありませんか。<br><a href="https://nextjs.org/docs/testing" target="_blank" rel="noopener noreferrer">https://nextjs.org/docs/testing</a><br>しかも、Jest + React Testing Libraryというやりたかった構成。<br>仕事ではJestでなくmochaを使っているので、Jestデビューすることにしました。（大して変わらんだろう。？）<br><br>基本はNext.jsのDocsの手順を追っているだけなので詳しくはそちらを見てほしいですが、ところどころ不要な設定は省いているので、とりあえず最短で動かしてみたい方に役に立つかもです。<br></p><h2 id="h67d2b7be6b">バージョン</h2><p>React　17.0.2<br>Next.js　11.1.2</p><h2 id="hb0d3f4053b">必要パッケージをインストール</h2><pre><code>// bash
npm install --save-dev jest babel-jest @testing-library/react @testing-library/jest-dom identity-obj-proxy react-test-renderer</code></pre><h2 id="h2e821172ad">Jestの設定</h2><p>ルートディレクトリに<code>jest.config.js</code><span style="color:#111111">&nbsp;を作って、以下の内容を書き写します。</span><br><span style="color:#111111">（Next.jsのDocsコピペです。。詳細は</span><a href="https://jestjs.io/docs/configuration" target="_blank" rel="noopener noreferrer">Jest docs</a>参照とのこと。<span style="color:#111111">）</span></p><pre><code>// jest.config.js
module.exports&nbsp;=&nbsp;{
&nbsp;&nbsp;collectCoverageFrom:&nbsp;[
&nbsp;&nbsp;&nbsp;&nbsp;'**/*.{js,jsx,ts,tsx}',
&nbsp;&nbsp;&nbsp;&nbsp;'!**/*.d.ts',
&nbsp;&nbsp;&nbsp;&nbsp;'!**/node_modules/**'
&nbsp;&nbsp;],
&nbsp;&nbsp;moduleNameMapper:&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;Handle&nbsp;CSS&nbsp;imports&nbsp;(with&nbsp;CSS&nbsp;modules)
&nbsp;&nbsp;&nbsp;&nbsp;https://jestjs.io/docs/webpack#mocking-css-modules&nbsp;*/
&nbsp;&nbsp;&nbsp;&nbsp;'^.+\\.module\\.(css|sass|scss)$':&nbsp;'identity-obj-proxy',


&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;Handle&nbsp;CSS&nbsp;imports&nbsp;(without&nbsp;CSS&nbsp;modules)
&nbsp;&nbsp;&nbsp;&nbsp;'^.+\\.(css|sass|scss)$':&nbsp;'&lt;rootDir&gt;/__mocks__/styleMock.js',


&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;Handle&nbsp;image&nbsp;imports
&nbsp;&nbsp;&nbsp;&nbsp;https://jestjs.io/docs/webpack#handling-static-assets&nbsp;*/
&nbsp;&nbsp;&nbsp;&nbsp;'^.+\\.(jpg|jpeg|png|gif|webp|svg)$':&nbsp;'&lt;rootDir&gt;/__mocks__/fileMock.js'
&nbsp;&nbsp;},
&nbsp;&nbsp;testPathIgnorePatterns:&nbsp;['&lt;rootDir&gt;/node_modules/',&nbsp;'&lt;rootDir&gt;/.next/'],
&nbsp;&nbsp;testEnvironment:&nbsp;'jsdom',
&nbsp;&nbsp;transform:&nbsp;{
&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;Use&nbsp;babel-jest&nbsp;to&nbsp;transpile&nbsp;tests&nbsp;with&nbsp;the&nbsp;next/babel&nbsp;preset
&nbsp;&nbsp;&nbsp;&nbsp;https://jestjs.io/docs/configuration#transform-objectstring-pathtotransformer--pathtotransformer-object&nbsp;*/
&nbsp;&nbsp;&nbsp;&nbsp;'^.+\\.(js|jsx|ts|tsx)$':&nbsp;['babel-jest',&nbsp;{&nbsp;presets:&nbsp;['next/babel']&nbsp;}]
&nbsp;&nbsp;},
&nbsp;&nbsp;transformIgnorePatterns:&nbsp;['/node_modules/',&nbsp;'^.+\\.module\\.(css|sass|scss)$'],
};</code></pre><h2 id="h21f2240c04">npmスクリプトにテストコマンドを追加</h2><pre><code>// package.json
"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "test": "jest"
}</code></pre><h2 id="h9773373aa1">準備完了😇テストを書く</h2><p><code>src/pages</code>直下の<code>index.tsx</code>でh1タグが正常に描画されるかどうかの簡単なテストを行います。</p><pre><code>// index.tsx

import&nbsp;React&nbsp;from&nbsp;'react';

export&nbsp;default&nbsp;function&nbsp;Home()&nbsp;{
&nbsp;&nbsp;return&nbsp;(
&nbsp;&nbsp;&nbsp;&nbsp;&lt;div&nbsp;className="container"&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;h1&gt;My&nbsp;Dashboard&lt;/h1&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&lt;/div&gt;
&nbsp;&nbsp;);
}</code></pre><p>同じディレクトリに<code>index.test.tsx</code>を作成します。</p><pre><code>import&nbsp;{&nbsp;render,&nbsp;screen&nbsp;}&nbsp;from&nbsp;'@testing-library/react';
import&nbsp;React&nbsp;from&nbsp;'react';
import&nbsp;Home&nbsp;from&nbsp;'./index';

describe('Home',&nbsp;()&nbsp;=&gt;&nbsp;{
  // h1タグのテキストが表示されることを検証
&nbsp;&nbsp;it('should&nbsp;render&nbsp;the&nbsp;h1',&nbsp;()&nbsp;=&gt;&nbsp;{
　　// コンポーネントをレンダリング
&nbsp;&nbsp;&nbsp;&nbsp;render(&lt;Home&nbsp;/&gt;);
　　// queryByTextは存在しない場合nullを返す。※getByTextの場合存在しないとエラーになるので注意
&nbsp;&nbsp;&nbsp;&nbsp;const&nbsp;h1&nbsp;=&nbsp;screen.queryByText('My&nbsp;Dashboard');
　　// h1がいることを検証
&nbsp;&nbsp;&nbsp;&nbsp;expect(h1).toBeTruthy();
&nbsp;&nbsp;});
});</code></pre><h2 id="hb92affa4b3">テストを実行</h2><pre><code>// bash
npm run test

&gt; my-dashboard@0.1.0 test C:\Users\shuhe\OneDrive\ドキュメント\code\my-dashboard
&gt; jest


&nbsp;PASS&nbsp; src/pages/index.test.tsx
&nbsp; HomePage
&nbsp; &nbsp; √ should render the heading (32 ms)


Test Suites: 1 passed, 1 total
Tests:&nbsp; &nbsp; &nbsp; &nbsp;1 passed, 1 total
Snapshots:&nbsp; &nbsp;0 total
Time:&nbsp; &nbsp; &nbsp; &nbsp; 4.442 s
Ran all test suites.</code></pre><p>テスト成功！<br><br>React Testing Libraryは、ユーザーの動作を模擬して色々パターン分けしてUIのテストができるので、機能追加の際などもテストが走ってくれていると安心感ありますね。<br>Jestのマッチャー関数が色々ありそうなので、どんどん試してみようと思います。<br></p><h2 id="hd1c6bbfc1b">追加情報</h2><p>公式Docsでは他の手段やもう少し便利に動かす方法もあるので念のため紹介します。</p><ul><li><code>Cypress</code>を使った方法も解説されています。自分はあまりなじみがないですがコード見る感じ直感的で面白そう。</li><li>コンポーネント内でcssモジュールやファイルをimportしている場合エラーになってしまうため、それらの為のmockファイルを作成します。（した方が良いです）</li></ul><pre><code>// __mocks__/fileMock.js
(module.exports = "test-file-stub")

// __mocks__/styleMock.js
module.exports = {};</code></pre><ul><li>初めにimportした<code>@testing-library/jest-dom</code>を用いると<code>jest-dom</code>の持つ便利なマッチャー関数(<code>.toBeInTheDocument()</code>など)を用いることができますが、いちいち呼び出し不要で使えるように、<code>jest.config.js</code>に以下セットアップファイルの呼び出しを追加し、ルートディレクトリに<code>jest.setup.js</code>を作成し、<code>jest-dom</code>の拡張をimportします。これで、カスタムマッチャー関数がどこでも使えるようになります。</li></ul><pre><code>// jest.config.js
setupFilesAfterEnv: ['&lt;rootDir&gt;/jest.setup.js']

// jest.setup.js
import '@testing-library/jest-dom/extend-expect'</code></pre><ul><li>プロジェクト内でModule Path Aliase（@/pages/~~的にpathを呼べるようにする設定）を用いている場合はそのtest側にも適用しないといけません。</li></ul><pre><code>// tsconfig.json or jsconfig.jsonにて以下のように設定している場合
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/components/*": ["components/*"]
    }
  }
}

// jest.config.jsに以下を追加
moduleNameMapper: {
  '^@/components/(.*)$': '&lt;rootDir&gt;/components/$1',
}</code></pre><ul><li>npmスクリプトのテストコマンドを<code>"test": "jest"</code>から<code>"test": "jest --watch"</code>とすると、修正毎にテストが走ってくれます！（僕は使いません！）</li></ul><p><br></p>

Next.jsにJestとReact Testing Libraryを追加してコンポーネントをテストする。

Next.jsにJestとReact Testing Libraryを追加してコンポーネントをテストする

<p>エンジニアとして、日々の業務や個人開発の中で学んだことを発信していきたいなと感じ、どういう手段で発信していこうか考えてみた。<br></p><h2 id="h4679204618">発信の目的</h2><h3 id="h50b5ed52bf">アウトプットによる知識の定着</h3><p>なにか分からないことを調べた時、その内容を言葉や文章にして一度アウトプットしないと、知識が体系化されなかったり、理解できている箇所とできていない箇所が曖昧なまま終わりやすい。<br>その知識が必要な時に、すぐに引き出しが開かなかったりする。<br>趣味なら勉強するだけで良いのだが、仕事にしている以上、知識は得て満足でなく生かせないと無駄になってしまう。</p><h3 id="h5b1c908c2f">説明する能力の維持</h3><p>コロナ過でフルリモートとなり、またWebエンジニアという職業柄、相手に自分の取り組みを分かりやすく説明しなければならない場面がかなり減っている。<br>前職のメーカーでは、少なくとも月に1回は重要な報告会があり、会社の上層部の人たちに対して、知識がなくともわかりやすく技術的なプレゼンテーションを行っていたが、<br>今はその説明をする自身がない、、<br>明らかに、言語化能力が落ちているのを感じている。<br>積極的に物事を説明をする訓練はした方が良いなと感じたのも、1つの目的。</p><h3 id="hc62a3d5b37">人脈形成</h3><p>正社員エンジニアをしているが、スタートアップの手伝いなど、個人でも仕事をどんどん受けていきたいと思っている。<br>（人脈形成というか、もっと抽象的に言うと「金」か。。）<br>今は以前バイトで手伝いをしていた会社さんから話を頂けたりなどで回っているが、新しい人脈形成も進めたい。<br>日々TwitterやYoutubeで発信をしている人たちを見ると、確かに、情報発信を続けていると「この人はこの領域に詳しい」という印象が定着するため、仕事につながりやすいだろなと感じる。<br>そのレベルで印象を定着させるのは一部のインフルエンサーだけかとも感じなくはないが、0 or 1ではないだろうし、何も発信しないよりは信頼度につながるだろうと感じる。</p><h3 id="h1b0cc88b98">承認欲求</h3><p>シンプルに、自分の持っている知識、能力が誰かの役に立ったり褒められると嬉しい。<br>QOL向上的な意味でも、有益な情報を発信する習慣を身に着けたい。</p><h2 id="hb6f8ad73e0">発信の手段を考えてみた</h2><h3 id="h6cfaa47bdb">ブログ</h3><p>本ブログに書いていく方法。<br>メリット</p><ul><li>テキストベースなので考えを整理しやすくとっつきやすい</li><li>ブログ自体のデザインや機能拡張も楽しそう。エンジニアとしてのアピールポイントになる。</li><li>もしコンテンツ販売などを行う場合も、手数料を低く運用できる。</li><li>本記事のような技術無関係な話題でもいける。</li></ul><p>デメリット</p><ul><li>プラットフォーム利用よりも圧倒的に読まれにくい（SEO頑張って長期目線で行くしかない）</li><li>読まれにくいと更新のモチベーションが落ち続かない</li></ul><h3 id="h4da2143927">Instagram</h3><p>メリット</p><ul><li>最近情報発信ツール化していて意外と穴場そう。</li><li>エンジニア系の発信している人がまだ少なく、将来性はあるかも。</li><li>多くの人の目につきやすい。</li></ul><p>デメリット</p><ul><li>あまり難しいことを書くと読まれなそう→書きたいことを書くという目的には合わない</li><li>長文は向かない→簡単な内容に絞られそう</li><li>テキスト入りの画像を作成する手間がある。デザインも必要。</li></ul><h3 id="hcf4474675d">Youtube</h3><p>話すのは不得意すぎて無理。<br>強いて言えば話す練習として良いかもしれないが、そこまでの労力をかけるモチベーションはそもそもない。</p><h3 id="h3679754b1f">Qiita・Zenn</h3><p>メリット</p><ul><li>読まれやすい</li></ul><p>デメリット</p><ul><li>「恥じない記事を」という心理が発生しそう。別に書きたいことを書けばよいのだが、気にしてしまいそう。鉞イヤ。</li></ul><h2 id="ha214098e44">まとめ</h2><p>なんとなく、メリデメをまとめるとブログが向いていそうかなと感じた。</p><ul><li>周りのレベルなど気にせず書きたい</li><li>技術以外も思ったことがあれば書きたい</li><li>長文でもなんでも書ける</li><li>SEOの勉強にもなりそう</li></ul><p>実際ブログはこれまで何度か挑戦しすべて挫折してきたので今回も続くかは正直自身は無いが、細々とでも継続したい。</p>

エンジニアとして学んだことの発信を始めたく、手段を考えてみた。

学んだこと発信を始めたく、手段を考える

<p><span style="color:#333333">個人開発品のグルメ質問サービス、PiTARIのバックエンドを作るのに使った技術。</span><br><br><a href="https://bubekiti.com/pypq72wx8s60" target="_blank" rel="noopener noreferrer">フロントエンドはこちら</a><br></p><h2 id="h48d8aea1d6">AWS Amplify</h2><p>バックエンドはAWS Amplifyを用いた。<br>Amplifyとは、AWSのリソースを簡単に組みわせて使えるサーバーレスフレームワーク。<br>AWS Black Belt Online Seminerでは、「Webフロントエンド、モバイルアプリの開発を加速さえるために作られたプラットフォーム」と定義されている。<br>イメージ的にはFirebaseのAWS版。<br>Amplify CLIをインストールすることで、コマンドライン上で対話的にバックエンドリソースを追加・開発・デプロイしていくことが出来る。<br><br>PiTARIは2者間で質問回答を行うサービス。<br>単純なCRUD処理と、マッチングの仕組みがあれば実現出来る。<br>またフロントはNuxt.jsでSPA構成だったので、バックエンドはできるだけシンプルに、且つ時間課金系のものは持ちたくない想いがあったので、Amplifyは最適だった。<br><br></p><h2 id="ha4dc22d627">Amplifyを用いた際のアプリ開発フロー</h2><p>PiTARIの開発は、いわゆるスキーマ駆動の逆のような開発を行った。<br>まずサービスの見た目をデザイン→フロントを実装しながらGraphQLのスキーマを考る→Modelを作成してフロントとAPI接続。<br>開発フローが大切なのは、チームメンバーの手が止まる時間をなくし生産性を高く保つ為と思うが、個人開発は全部自分で作るのでその心配はあまり無い。<br>基本的には毎日作りたいところを作るみたいな感じだった。<br>特にAmplifyではフロントプロジェクト内に生成されるGraphQLスキーマファイルにモデル構造を記述し”Amplify push”コマンドを叩くだけで、バックエンドのデプロイが完了する。<br>（基本は開発初期にモデル設計はすべて行ったが、）これにより見た目を作りながら過不足はその場でモデルを修正してデプロイ、テストしてOKなら次の画面に、、といった感じで開発を進められる。<br>ページ毎にフロントとバックを同時に進められるので、1日の開発のマイルストーンも明確でテンポ良くすすめることができた。<br></p><h2 id="h048e0c01f9">API権限設定</h2><p>Amplifyで作成するAPIでは、エンドポイントごと、またエンドポイント内のカラムごとに認証レベルを分けることが出来る。<br>例えば、通常のフロントアプリからのアクセスはCognito認証ユーザーのみにして、バックエンド間の連携はIAM認証と行った具合でアクセス権限を分けられる。<br>また、カラム毎に閲覧はPublic公開し、作成と編集はCognito認証ユーザーの且つデータのオーナーのみ、といった権限切り分けも可能だった。<br>PiTARIの場合、質問チケットはPublic公開、購入情報や質問回答内容はマッチングした2ユーザーにしか公開されないといった権限分けが発生したが、Appsyncの設定数行のコードで実現できてる。<br></p><h2 id="h4931f0b05c">検索</h2><p>PiTARIの重要な機能の１つとして、質問チケットの検索機能がある。<br>探すお店の都道府県や詳細エリア、予算、ジャンル、回答者のSNSアカウント、その他諸々を指定してチケットを検索出来る必要がある。<br>一方でDynamoDBはキー・バリュー型であり、検索が得意でない。<br>ソートキーを多数設定してクエリする方法があるが、Amplifyでは何故かDynamoのソートコマンドの制限が多く、要件を実現させることができなかった。<br>Amplifyでは検索性を上げるため、対象のモデルに@seachable属性を与え(= Elastic Searchを導入)全文検索を追加する方法があり、開発で試したところ最高に便利だった。<br>しかし問題は、Elastic Searchは時間課金。。。一定時間は無料なのだが、2環境に入れると2倍になるため、あっという間に月あたり数千円の請求が発生していまい導入ボツとなった。。<br>そこでPiTARIでは少し強引だが、検索クエリは直接APIコールするのでなく、一度Lambdaを間に噛ませ、LambdaからAPIコールを行い全件を取得、Node.jsの自前コードで検索・ソートを行いレスポンスに返すことで検索機能を実現している。<br>今の所、速度も全然早いし、問題なく使えている。<br></p><h2 id="hc096326ed1">認証</h2><p>認証にはAWS Cognitoを用いた。<br>"amplify add auth"で、Cognitoリソースが割り当てられる。<br>サインアップ、ログイン、ログアウト、パスワード再発行など、一般的に必要な機能はすべてSDKで１コマンドで完了するので、技術的に特に工夫した点はない。<br></p><h3 id="hc4d6411acb">工夫点</h3><p>Google認証をメインの認証方式とした。<br>Webアプリにあふれる中、このような零細アプリのためにIDパスワードを設定してもらうのは避けたいと思い、数クリックで完了できるOAuthに拘った。<br>事前登録を募った際も250名登録頂いた中で9割以上の人がGmailだったため、<br>ログイン画面では、Google認証ボタンを中央に大きく設置しできるだけOAuthに誘導し、IDPASSの認証はサブとして隅っこに配置した。<br></p><h2 id="h1bbd88e977">Function</h2><p>バックエンドで行うロジックはすべてAWS Lambdaで実行している。<br>こちらも、"amplify add function"で簡単にLambda関数をセットアップ出来る。<br>DynamoDB streamingによるトリガー実行やCloud Watchの定期実行、Appsyncの接続やAuth連携もほぼ自動で作ってくれる神機能。<br><br>PiTARIで必要なバックエンドロジックは、</p><ul><li>Stripeの決済処理</li><li>質問回答のステート管理</li><li>ユーザーのスコアや売上計算</li><li>メール送信</li><li>食べログのリンク取得</li></ul><p>などであった。<br>これらをフロントのプロジェクト内で"add function"で作成したファイルに記述し”amplify push”するだけでLambldaへのデプロイが完了するので非常に効率的に開発できた。<br>質問が投稿された際のメール通知機能は、DynamoDB streamingでInsertを検知してFunctionをトリガ起動といった流れだが、Amplify CLIでセッティングするとテンプレートコードが入った状態で作ってくれるので、ほぼSendGridのサンプルコードをコピペのみでできてしまう。<br></p><h3 id="hc4d6411acb">工夫点</h3><ol><li>PiTARIでは一部Webスクレイピングも行っており、こちらもAppsync経由で検索文字列をLambdaに引き渡し、LambdaからPythonでWebスクレイピングを行い、取得したデータをJSONに変換しレスポンスにわたす処理も行っている。</li><li>NoSQL DBの課題の１つがトランザクション処理ができないということが言われているが、DynamoDBはトランザクションに対応している。かなり処理が重くなりDynamoのメリットが削がれるため、導入は最小限とすることが推奨されているが、PiTARIでも決済処理の箇所だけはデータの不整合は絶対避けたかった為、一部トランザクション処理を入れた。</li></ol><p><br></p><h2 id="h6c11353d22">Storage</h2><p>画像保存はAmazon S3で行った。<br>こちらも、"amplify add storage"で1発だ。<br><br></p><h2 id="h37941d78f7">決済、メール配信</h2><p>決済はStripe、メール配信はSendGridを用いた。<br>どちらもほぼドキュメント通りの実装なので特に工夫点は無い。<br>Stripeはドキュメントがとてもわかりやすい。サポートチャットも英語でちょっとテンション高めだが、即レスでしっかり対応してくれてとても良かった。<br><br><br>Amplifyは簡単なようで、ブラックボックス化されているところもありエラーにはかなり苦しんだ。特にCloud Formationが壊れると手に負えなく、一度環境ごと削除といった自体も何度か発生した。<br>1環境壊れてもバックアップを常に持ってmasterを死守する仕組みを用意しておく必要がある。<br><br>Amplifyに関しては、細かい設定やそれによって実現出来ることが多数あり書きたいことが無数にありまとまらないのだが、<br>今回は概要ということで、細かい話は別途小出しで記事にしていきたい。<br></p>

個人開発で使った技術を振り返る~バックエンド編~

個人開発で使った技術 ~バックエンド編~

<p>個人開発、グルメ質問サービスPiTARIを作るのに使った技術を紹介する。<br></p><h2 id="h5dc0967264">フロントエンド</h2><ol><li>Nuxt.js (Vue2)</li><li>Vuetify</li></ol><h2 id="ha2cc149486">バックエンド</h2><ol><li>AWS Amplify (Cognito, Dynamo DB, AppSync, Lambda, S3, Elastic Search)</li><li>Stripe</li><li>SendGrid</li><li>microCMS</li></ol><p>functionの言語はNode.jsと、一部Python<br><br>全体としては、サーバーレスSPAの構造だ。<br>サーバーレスで作った大きな理由はコスト。<br>数人にしか使われないというリスクも想定すると、時間課金のサーバーは使いたくない。<br><br>それぞれの技術を使ってみてどうだったか的な観点で書きたいが、<br>ボリュームがあるのでフロントとバックエンドで記事を分ける。<br><br>今回はフロントエンド。<br></p><h2 id="h69bcc6cbbc">Nuxt.js</h2><p>今どきのWebアプリは基本VueかReactを使うのが一般的なようだが、自分はたまたまVueから学んでいたので扱いやすいVueを用いた。<br><br>最近はISRなどのパフォーマンス周りの技術でNext.jsの注目度が高く憧れたが、自分はあまり知らなかったのでVueを採用した。<br>（ちなみにこのブログはNext.jsで作っている）<br><br>また、PiTARIはクライアントサイドでレンダリング(CSR)しており、サーバーサイドレンダリング(SSR)は行っていない。<br>サービスの特性上、Publicに公開するコンテンツが無くSEOをそこまで気にしていないのと、そこまで重い処理がフロントで走るわけでもないので、できるだけシンプルな作りにしたくCSRのみで作った。<br>（あとは個人的に、すべてレンダリングされた後に全体が表示されるよりも、先にぱっと画面が出てローディングアイコンが出てくれたほうが安心感がある）<br><br>CSRならNuxt使う意味ある？と思うかもしれないが、ファイルシステムルーティングを使えるメリットは大きい。<br>一度Vue CLIでアプリを構築したことがあるが、フォルダのディレクトリ構造とVue Routerの構造をそれぞれ設計するのはとても面倒。<br>その他にも、Nuxt専用のプラグインはnuxt.configに書くだけで使えるものもあったり、お手軽感がすばらしい。<br>一度Nuxtを体験すると戻れない。。<br></p><h2 id="hd4f5544cc9">Vuetify</h2><p>アプリ内のUIは基本Vuetifyに頼っている。<br>Vuetifyばかりでは建て売り感が出てしまうので、LPはHTML+CSSでコーディング、その他は基本VuetifyでUIを作った。<br>（個人的には、VuetifyでもスタイルのAPIをフル活用＋ ::v-deepで強引にスタイルを調整していけば、そこそこオリジナル感は出ると思っている。）<br><br>Vuetifyで特に便利だったのが、フォームバリデーション。<br>メインの機能が質問回答をテキストで行う箇所故、フォームを入力→バリデーションの実装が多い。<br>Vuetifyのv-formコンポーネントを用いれば１行でバリデーション実施の処理を書ける、<br>v-text-field、v-textarea、v-selectにはエラーメッセージのAPIも用意されていて、少労力で実装できた。<br><br>自分の中では、PiTARIのようなツール寄りのサービスにはVuetify、メディア系の見た目の作り込みが重要なものはTailwind CSSなどが良いのでは、と思った。<br>このブログはTailwind CSSを用いたが、デザインは自由にできてレイアウトやレスポンシブは爆速で出来る感じはとても良いなと。<br></p><h2 id="h6e312b3deb">課題</h2><p>今回の開発で、自分自身の技術的課題として感じたのがTypeScriptだ。<br>自分はまだTypeScriptの開発経験が無い。<br>この開発を始めるまでは「型？そんなに大切か？」くらいに思っていたが、この開発を持ってその重要性を肌で感じた。<br>JSは臨機応変に型推論してくれて記述量を抑えられる便利な言語だが、サイトの規模が大きなるとそれが仇となってしまう印象。<br>”can not read XXX of undefined”のエラーには相当苦しんだ。<br>想定していない型の値が入った時点ではエラーにならず、特定の条件で利用した場合にのみ型エラーが"ブラウザ上"で発生。これが問題だ。<br>VueとTypeScriptは相性が悪いようだが、Vue3のComposition APIでは"this"を使わずに実装できそうだし、JSXも使えるということでTypeScriptもどんどん導入していけそうだ。<br>というか、Reactに移っても良いかもしれない。<br><br>次回はバックエンドについて書く。</p>

個人開発で使った技術を振り返る~フロントエンド編~

個人開発で使った技術 ~フロント編~

<p>2020年12月から、Webでグルメ質問サービスを、開発している。<br>開発は自分、営業マーケティングを友人に任せての2人体制で、4月頭にβ版リリースを予定している。<br><br>現在事前登録を受付中で、ありがたいことに240名から登録頂いている。<br><br><a href="https://pitari.me" target="_blank" rel="noopener noreferrer">サイトはこちら</a><br></p><h2 id="h28e13924eb">サービスの概要</h2><p>「飲食店選びを、詳しい人に直接質問してお店情報を教えてもらう」というもの。<br><br>教える側の人は有料または無料で質問権を公開し、教えて欲しい人は質問権を購入し質問する。<br><br>フリマアプリの、質問権を取り扱うバージョンだ。<br><br>“レビューサイトよりも信頼できる人に直接教えて欲しい”<br>のニーズを、ユーザーがSNS等で持っている信頼・権威性と組み合わせて解決したい。<br></p><h2 id="h3d1cd409a0">なぜ作ろうと思ったか</h2><p>サービスの概要を見て「面白そう！使ってみたい！」と感じる人は少数派な気がする。<br><br>実際、自分の友人に説明しても「ニッチすぎない？お店教えてもらうだけにお金払う人いる？」と言われることもある。<br><br>この案をもって開発に踏み切った理由は3つある。<br></p><ol><li>自分自身の肌で感じたちょっとしたニーズ</li><li>超ニッチ✖️自分は使いたい</li><li>単純に個人開発をやってみたかった</li></ol><p><br></p><h3 id="h4c0b9e2fcb">自分自身の肌で感じたちょっとしたニーズ</h3><p>自分は数年前、インスタグラムでグルメ記録活動をしていた。<br><br>ひたすら食べたものの写真を載せていくだけのアカウントだが、意外とフォロワーが伸びた。<br><br><br><img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/971781329d344a979860fce3982bc821/FDB33BFC-0F9C-453F-B374-4C81F3D366FB.PNG" alt=""><br><br>顔を出したり面白い文章を書くわけではないのに、いいねやコメントを貰えるので、グルメ情報を欲している人は多いんだなと感じた。<br><br>そしてこの時たまにあったのが、「〜界隈でおすすめの飲食店教えてください」という知らない人からのDM。<br><br>食べログやGoogleが圧倒的情報力を持つ中、フーディーの端くれのような自分にも、直接聞きたいニーズは少なからずあった。<br><br>このサービスの営業マーケティングを担当している友人はフォロワー2万人越えのグルメインフルエンサーなのだが、この手のDMが多すぎてストレスになるレベルだと言っていた。<br><br><br>一方で、インフルエンサー側のニーズはなんといってもマネタイズ。<br><br>一部のフォロワーが2万を超えているような人や、ただのフーディーでなくキャラや見た目の良い人ははPR案件で収益を得ているようだ。<br><br>しかし基本、グルメ分野でのマネタイズは難しい。<br><br>ブログを書く人をよく見るが、個人ブログがSEOで食べログレビューに勝つのはほぼ不可能だ。<br>最近では、ググったところでWebサイトよりも上にGoogle mapsで候補が表示され、解決してしまう始末だ。<br><br>アフィリエイトは、お店を探しに来た人に物を売ろうとするのはお門違いとなってしまう。<br><br>動画にしても、アル中カラカラさんのようなスタープレーヤーがいる中で「美味しそう」だけのコンテンツでは時間を使ってもらえない。<br><br><br>グルメ情報発信のつらみを長々と書いてしまったが、「詳しい人に直接聞きたい」と「グルメの知識をマネタイズしたい」を同時に満たせないかと思ったのがこのサービスの始まりだ。<br></p><h3 id="h82ece6559a">超ニッチ✖️自分は使いたい</h3><p>個人開発でそれなりに使ってもらえるものを作る条件として、<br></p><ul><li>超ニッチ領域</li><li>自分だったら使う</li></ul><p>この２点が必須と思っている。<br><br>今は世の中、webサービスで溢れている。しかも完成度の高いものばかり。<br><br>「どんなジャンルでも質問できるサイト」や「グルメ総合サイト」で勝つのはまず無理だろう。そもそも個人では作りきれない。<br><br>スタートアップや個人の開発でよく言われる事だが、解決したい問題の具体度を上げて、1000人に1人にでも「あっこれが欲しかった！」と言ってもらえるようなプロダクトを目指したい。<br><br>また自分の場合だが、このサービスがあったら普通に使いたい。<br><br>旅行先では地元の人が好む店を知りたいし、食べログ3.0台の良店を知りたい。<br><br>そして大人になる程時間がとにかく大切になる故、1回の食事が失敗に終わるダメージは大きい。<br><br>いつもインスタで見ているような人に条件を伝えてオススメ店を直接提案してもらえるなら500~1000円普通に払うなと思ったので、作ってみる価値はあると思った。<br></p><h3 id="hc7a6d7ffd9">個人開発をやってみたかった</h3><p>僕は2020年からWebの勉強を始めた新米者だ。<br><br>スタートアップ企業に入り4ヶ月経ち、「調べながらなら、なんとか自分でサービス作れるかも」という状態になったので、第一弾として作ってみることに決めた。<br><br><br><br>もうすぐローンチを控えており、<br>バグなどで大変な目に合う未来も見えるが、やると決めたのでやってみる。</p>

個人開発でグルメ質問Webアプリ「PiTARI」を作る

グルメ質問アプリ構想

<p>ブログサイトをリニューアルした。<br>このドメインでサイトを立ち上げて1年も経っていないが、今回で2度目のリニューアル。<br>これまでの2サイトの見た目は、、<br><br><strong>1代目</strong><br><img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/5e11b1e767a6498bb24b443aa129dbe2/bubekiti.com.png" alt=""><br><br><strong>2代目</strong><br><img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/eb43d1d637484763a9ed6fddee1d7c6f/%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-03-22%2023.41.48.png" alt=""><br><br><strong>3代目(今回)</strong><br><img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/c84ebea357644eef8630c3b6c26f0c73/%E3%82%AD%E3%83%A3%E3%83%97%E3%83%81%E3%83%A3.PNG" alt=""><br><br>今回が1番シンプルかも</p><h2 id="h94260aa88b">なぜリニューアル？</h2><p>React / Next.jsを触ってみたかったから。。<br>これまで仕事でも個人開発でもVue.js / Nuxt.jsのみだったが、最近のReact / Next.jsの勢いを見て、置いていかれたくない感情が大きくなってしまったｗ<br>普通ホームページは集客が目的だけど、僕の場合は触ってみたい技術の練習用。<br>記事の画像を毎回選ぶのが面倒で、だけど何かアイコンは欲しいなと思い絵文字をアイキャッチ替わりに使っている。（Zennのマネすみません。）<br>絵文字をMacのキーボード上のバー(?)から選ぶのが地味に楽しい。</p><h2 id="ha8c91e962c">Reactを触った感想</h2><p>Reactを触った第一印象は、VueよりもJavaScriptっぽい。(浅い)<br>ブログ程度なら大差ないけど、複雑な処理を行う場合はReactのほうがJavaScriptの知識がより必要になるなという印象。<br>ただし、同じ処理を書いた場合はReactの方がやや短くなりそうだなと。Vue特有の"methods"や"computed"といった呪文を書かない分。<br>これはサイトの規模が大きいほどメリットなんじゃないかな。<br>ISRやダイナミックImportなど、ぼちぼちこのブログにも取り入れてみたい。</p><h2 id="h3f851ef1db">どういうブログ？</h2><p>今回のリニューアルでは、ホームページ型をやめてシンプルなブログにしてみた。<br>理由は、静的ページを作るのが面倒だったから、、<br>APIを叩いてJSONを加工してHTMLに反映させる。このフロントの基本動作を試し打ちするにはブログがちょうど良い。<br>とはいえ、せっかく作ったので情報発信ももう一度始めたいなと思いこの投稿に至る。いつまで続くかわからないが。。<br>以下の内容で発信を続けていければなと。</p><ol><li>技術的な発信 (DEVカテゴリー)</li><li>個人開発の運営記録 (DEVカテゴリー)</li><li>その他個人的な考えやグルメログ (LIFEカテゴリー)</li></ol><p><br>前のブログでは初学者向けお役立ち情報を狙って書いていたけど、今回はPVなど気にせず思ったことを綴っていくスタイルかなと。<br>特に今は個人開発で<a href="https://pitari.me" target="_blank" rel="noopener noreferrer">PiTARI.me</a>というグルメ質問サービスを作っていて、<br>初めて個人で0→1のビジネスに挑戦することもあって、ニーズにマッチさせられるか、はたまた全く使われず閉鎖するのか、開発・運営の過程を記録できたらと思っている。<br><br></p>

Next.js + TypeScript + microCMS + VercelでSSGのブログにしてみました。

bubekiti blog

New Posts

Next.jsにJestとReact Testing Libraryを追加してコンポーネントをテストする

学んだこと発信を始めたく、手段を考える

個人開発で使った技術 ~バックエンド編~

個人開発で使った技術 ~フロント編~

グルメ質問アプリ構想

ブログをリニューアル