この記事を書いた僕は、現在WordPressのテーマ作成に取り組んでいます。 ローカル環境で作業する方法に、いろいろなツールを試した中で、「Local by Flywheel」というツールがとても簡単で良きでした。 ある程度WebAppに精通している方であればDockerを使ってしまうのが手っ取り早いと思いますが、 案件によりDockerの利用に制限がある場合もあったり、 そもそもDockerになじみがなければかなりの学習コストがかかってしまいます。 手っ取り早くWordPressを触りたいという方向けに、「Local by Flywheel」を用いた簡単な構築方法を解説します。 <h2 id="he16f3100ea">Local By Flywheelを使えば、5分でWordPressのローカル環境を構築可能</h2><h3 id="h4f678cf506">そもそもローカル開発環境とは？</h3>文字通り、オンライン上でなく、ローカルエリア（オフライン）でプログラムを編集したり表示を確認したりすることです。 制作途中のWebサイトをオンライン上で公開する訳には行きませんので、自分のPC内に仮想的なサーバー（＝ ローカル環境）を作って、他の人が見られない状態で作業を進めます。 <h3 id="hcdf081db16">WordPressのローカル環境はエディタとブラウザだけでは不十分</h3>HTML/CSSだけであれば、テキストエディタで編集して、HTMLファイルをブラウザにドラッグ＆ドロップすれば表示でき、エディタだけあれば制作することができます。 一方で、WordPressを使った動的サイトとなると、データベースとも連携した結果を表示する必要があり、ドラッグ＆ドロップだけでは表示できません。 初めてこの壁にぶつかった時、<a href="https://dotinstall.com/" target="_blank" rel="noopener noreferrer">ドットインストール</a>などでローカル環境の作り方の動画をみて学んだという方は多いのではないでしょうか。 僕も、初めてのローカル環境の作り方はドットインストールで学びました。「結構めんどくさいな」と思った記憶があります。 <ul><li>Virtual Boxをインストール</li><li>Vagrantをインストール</li><li>FTPツールをインストール</li><li>WordPressのHPからファイルをダウンロード</li><li>FTPツールでアップロード</li></ul> こういった流れだったと思います。 ProgateでHTML/CSSを学んだくらいの人（僕がそうだった）が見ても意味わからないですよね。 機械音痴な僕はこの作業が面倒すぎてWeb制作を諦めようと思ったくらいです。 <h3 id="h75bac4829f">Local By FlyWheelが全て解決</h3>今回紹介する、「Local By Flywheel」を用いれば、面倒な作業が全部不要になります。 「Local By Flywheel」は、デスクトップアプリの感覚で、<ol><li>新規WordPress作成ボタンを押す</li><li>ブログ名やログイン情報を入力</li><li>環境構築完了→編集開始</li></ol>タイトルに「5分」とありますが、ぶっちゃけ2分かもしれません。それくらい簡単です。 それでは具体的なステップを紹介していきます。 <h2 id="h70a84c73be">Local By Flywheelで自作テーマファイルの編集開始までの手順</h2><h3 id="hd44f9f23fa">Local By Flywheelのインストール</h3>公式ページにアクセスしてください。 <a href="https://localwp.com/" target="_blank" rel="noopener noreferrer">Local By Flywheel</a> 赤枠の「DOWNLOAD」をクリック。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/cd35b7824bc84fcdad77cc654ee3d390/%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-2020-06-24-7.17.24-1024x532.png" alt=""> OSと、格情報を入力。 ※いらんメールが来るようになるので注意 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/de1b4d2187254924a5f6560141a3d2a8/%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-2020-06-24-7.18.00-1024x532.png" alt=""> あとは何もせずインストールされます。 インストールが完了したら早速開いてください。以下がLocal By Flywheelのトップ画面です。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/b6d5d827f35846c481b62c665e2b3c23/%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-2020-06-24-7.26.27-1-1024x691.png" alt=""> Local Sitesって書いてますよね。ここに３つありますが、これは僕がすでに作っているものなので無視してください。 １つのWordPressサイトごとに、ここに１つのLocalSiteとして作っていきます。 新しくWordPressサイトをローカル環境に作成するには、左下、赤枠部をクリック。すると、以下の画面に続きます。サイト名を入力してください。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/0b22847937cf49679768b4d226e0007d/%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-2020-06-24-7.31.12-1024x691.png" alt=""> 設定の種類が２種類出ますので、「Prefered」でOKです。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/7e40a09bec50488e9e43517da143df57/%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-2020-06-24-7.30.46-1024x691.png" alt=""> WordPressの管理画面ログインユーザーネーム、パスワード、メールアドレスを入力。こちらは、管理画面ログインに用いるので忘れないでください。 入力したら「ADD SITE」をクリック。以上。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/21380c787031405fa38e97684ba205b5/%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-2020-06-24-7.33.42-1024x691.png" alt=""> これでローカル開発環境の構築は完了です。 通常は、WordPressの公式サイトにアクセス、ファイル群をダウンロードして作業ディレクトリに保存する手間がありましたが、 Local By Flywheelは勝手にダウンロードしてきてくれます。 数十秒かかると思いますが、以下のトップ画面になっていれば完了です。 新しいサイトが追加されているのがわかると思います。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/7e13018679f5413daac42733c4bd2deb/%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-2020-06-24-7.39.51-1024x691.png" alt=""> 先ほどは「test1」でしたが「test11」に変更しています。気にしないでください。 基本的に操作を覚える必要があるのは上記の画像の３つのボタンだけです。 ①　ローカル環境でのサイトの起動/停止ボタン　→基本的にずっと起動でも問題ありません。 ②　WordPressの管理画面ボタン　→WordPressログイン画面に進みます。（ブラウザが開く） ③　サイト閲覧ボタン　→押すとブラウザが開き、ローカルでサイトを閲覧できます。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/7cc0f3ce757d4ee9b9e0f0f2c9d07990/%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-2020-06-24-7.46.53-1024x691.png" alt=""> ②のボタンを押して、ログイン画面に進んでみましょう。 ブラウザでいつものログイン画面が開きますので、先ほど設定した物を入力します。 ※こちらはあくまでローカル環境で動作してます。 ログインに成功すると、いつもの管理画面です。 英語の表記になってしまっているので、下記設定画面から、日本語に変更できます。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/63da2ef1c2514e79b3e20bdd3042cc99/%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-2020-06-24-7.47.30-1024x576.png" alt=""> 続いて、テーマファイルの編集する場合ですが、Local By Flywheelの画面に戻って、下記赤枠箇所をクリックしてください。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/3494daa46ea644799e431c1b4866739d/%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-2020-06-24-7.52.05-1024x576.png" alt=""> WordPressの構成ファイルが、ファインダーで開きます。テーマファイルを編集する場合は、app &gt; public &gt; wp-content &gt; themes でテーマのディレクトリまで移動してください。 <img src="https://images.microcms-assets.io/assets/7ffcd6fa069348bc81d68b177e41d955/27a386c351214767bf0998afdcd206b3/%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-2020-06-24-7.53.31-1024x576.png" alt=""> あとは、テーマファイルをエディタで編集して保存すれば、編集結果は先ほどのブラウザ表示に即座に反映されます。 オートリロードはついていませんが、gulpなどと組み合わせればできますね。 設定は以上になります。めっちゃ簡単＆便利ですね。コマンドライン操作は一切不要です。 <h2 id="h031614e9d2">めっちゃ簡単にWordPressのローカル環境ができた</h2>ドットインストールで学ぶと、「作業環境作るだけなのにめっちゃ面倒」って思いますよね。 あるんです、こういう便利なやつ。 これからWordPressでWeb制作するという方、ぜひ使ってみてください。 それでは、今回は以上です。

WordPressのローカル環境構築にLocalbyFlywheelを使ってみたので解説する。

WordPressのローカル環境構築にLocal by Flywheelを使ってみた

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

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

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

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

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

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

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

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

グルメ質問アプリ構想

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

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

Bubekiti Blog

New Posts

WordPressのローカル環境構築にLocal by Flywheelを使ってみた

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

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

グルメ質問アプリ構想

ブログをリニューアル