はじめに

Vue3で作成したプロジェクトでvue-routerを使おうとしたが、なぜかうまくいかず

調べてもあまり情報がなかったのでここに記録することに決めた！

Vue3でvue-routerを入れると、、

npm install vue-router

main.js

import { createApp } from 'vue';
import { createRouter, createWebHistory } from 'vue-router';

import App from './App.vue';
import TeamsList from './components/teams/TeamsList.vue';
import UsersList from './components/users/UsersList.vue';


const router = createRouter({
    history: createWebHistory(),
    routes: [
        { path: '/teams', component: TeamsList },
        { path: '/users', component: UsersList },
    ]
})

const app = createApp(App)

app.use(router);

app.mount('#app');

 WARNING  Compiled with 2 warnings                                                          23:00:16

 warning  in ./src/main.js

"export 'createRouter' was not found in 'vue-router'

 warning  in ./src/main.js

"export 'createWebHistory' was not found in 'vue-router'


  App running at:
  - Local:   http://localhost:8080/ 
  - Network: http://192.168.11.20:8080/

vue-routerがありませんよ！！っと言われる。。なんで？？！

Vue3ではvue-routerも新しくしないとダメ

https://github.com/vuejs/vue-router-next

https://next.router.vuejs.org/installation.html#direct-download-cdn

これらの公式ドキュメントを見ると

npm install vue-router@next

「@next」がついてる！
どうやら今のところはこのコマンドで入れないといけないようです。。。
知らんかったーーーー。エラーメッセージ とかつけといてくれよ。。。

At first.

This content is written by GCP Begineer.
So, this content may isn't Best Practice.
Please read this content as reference information.

What I want to achieve in this article.

• Understand GCP's Serverless Architecture.
• Understand GPC's Local Programing Environment.
• Recall specifications of Spring Boot2.
• Recall specifications of Vue.js
• Understand OpenIDConnect.

Serverless configuration to be adopted.

• GCP CloudRun (Backend) -- No Kubernetes
• Vue.js (Frontend)
• Java + Spring Boot2
• Doma2
• MYSQL on CloudSQL

Configuration.

• Frontend Layer is Static Html files with Vue.js on Firebase Hosting.
• Backend Layer is RestAPIs.
• Used Doma2 for Database Access

At the end.

First of all, I will create this configuration.
After that, if this configuration is run short I will change or I will added components.

Next time, Start Create Configuration.

thanks for reading this contents.

kazuya.

こんにちは！SIerでJavaプログラマをしているゆうきデザイン（@yuki_design_gr）と言います。

Qiita初投稿として、自己紹介も兼ねて
"SIerエンジニアからWeb系フロントエンドエンジニアに転身するために今やっていること"
というテーマで書いてみようと思います。

同じような境遇にいる人の道しるべの1つになりますように！

目次

1. 自己紹介
2. なぜWeb系を目指すのか
3. SIerエンジニアからWeb系フロントエンドエンジニアに転身するために今やっていること

1. 自己紹介

東京在住の20代半ば。

学歴

東京外大韓国語専攻卒業

職歴

新卒で大手SIerに入社し、アカウント営業を担当(10ヶ月)
→SE(現職。Java・.NET・Oracleのコーディング実務1年半)
→Web系企業への転職準備中

モットー

技術とデザインのことをポジティブに共有すること

目標

・世の中をポジティブにするWebサービスを作ること
・ビジネスを始めたい・サービスを作りたい友だちをIT・デザイン面でサポートすること

趣味など

韓国語と英語は日常会話レベル
持久系のスポーツが好き（陸上・水泳。社会人になってからもたまにやってる）
実写の動画編集
映画・音楽・コーヒー
ミスチルが生まれた時から好きで、人生ピンチの時に助けてくれる存在（←いま）

さあ、本題に入ります！

2. なぜWeb系を目指すのか

①新しいものを追いかけるのが好きだから

音楽や映画などのエンタメや好きで、
SI業界よりもトレンドの移り変わりが激しいWeb業界が楽しそうに見えるため。

②Webサービスを作りたいという目標があるから

自己紹介でも書いたように
世の中をポジティブにするWebサービスを作る
という目標があり、
SI業界に身を置くよりも目標実現への近道だと思っています。

③システムの裏側の処理よりも見た目に魅かれるから

Javaエンジニアをしていてプログラミングは基本的に全般楽しいですが、
JSPやCSS等のシステムの見た目の開発が楽しく、
また他のメンバーが気にかけないレイアウトのズレなどに何度も気づくことができました。

そのため、まずはWebデザイナーやUI・UXデザイナーに興味を持ち、
デザイナーのための勉強会などに参加してきました。

しかし、自分のプログラマとしての経験を活かす×システムの見た目に寄与できる
というフロントエンドの技術が一番しっくりくるなあと今は思っています。

3. SIerエンジニアからWeb系フロントエンドエンジニアに転身するために今やっていること

①フロントエンド技術に触れること

結局はどの言語がベスト！とかはなさそうなので
今は色々触ってみてます。

フロント: react, vue, rails
バックエンドやインフラ等: node, ruby, docker, laravel
その他: TypeScript, Sass, Bootstrap

色々触れる今の時期が一番楽しいですね。
何かを極めた方が勉強になる気もしますが。

個人的にはnode + react(またはvue・angular) + TypeScriptがアツい気がします！
全部jsで書けるなんて！

②フロントエンド技術を用いたWebアプリを作ってみること

上記のそれぞれの言語を使って
簡単なSNSやTodoリストをチュートリアルを見ながら作成中です。
ネット上に公開するところまでやりたいです。

③SNSやGitHub、Qiita等でのアウトプット

個人的に苦手であまりできていないアウトプット。
でも見てる人との交流が生まれたり、自分の特性や技術力を客観視できる機会と思って、
定期的に取り組んでいきたいです。

---

この投稿の内容は以上です。

ここまで読んでいただきありがとうございます。
これからも有益な情報をポジティブに発信していきたいです。

ぜひ、Twitter（@yuki_design_gr）のフォローもよろしくお願いします。

Vuejsの学習のまとめ

目次
1.　Vuejs2でのthisの使い方
2.　上記の親ファイルのコード
3.　データ渡しのメソッドについて
4. props, $emitをEventManagement.vueに書く

Vuejs２でのthisの使い方

<template>
<div>
<p>Good({{ halfNum }})</p>
<button @click="increment">+3</button>
</div>
</template>

methods: {
    increment() {
      this.$emit("my-click", this.number + 3);
}
  }
};

上記の親ファイルのコード

v-bindまたは:{{オブジェクト名}}を記述する。

テンプレートにイベントを登録する

<template>
<div>
  <GoodHeader></GoodHeader>
  <p>{{ number}}</p> 
  <GoodNum :number="number" v-on:my-click="number = $event"></GoodNum> 
//$eventとnumberをレンダリング
  <GoodNum :number="number" ></GoodNum>
</div>
</template>

データ渡しのメソッドについて

親から子へのデータの受け渡しで、$eventとして、登録でき
テンプレートを作成する。

  methods: {
    increment() {
      this.$emit("my-click", this.number + 3);
    }
  } 
};

$emitを子から親へデータの受け渡しを設定する

親側のコード

<template>
<div>
  <keep-alive>
    <component :is="currentComponent"></component>
  </keep-alive>
  <div>
   <h2>イベント管理</h2>
   <EventManagement v-model="eventData.title"></EventManagement>　
</template>
export default {
  data() {
    return {
      currentComponent: "sample"
      eventData: {
        title:"入力内容"
      }
    };
  },
  components: {
    sample,
    EventManagement
}

props, $emitをEventManagement.vueに書く

親ファイルのテンプレートのコードを省略できる。

<template>
    <div>
        <label for="title">Theme</label>
        <input
         id="title"
         type="text"
        :value="value"
        @input="$emit('input',$event.target.value)" 
        >
        <pre>{{ value }}</pre>
    </div>
</template>

<script>
export default {
    props: ["value"]
};
</script>

はじめに

学生時代にサービスをリリース・運用するために必要な知識がゼロの状態で、アプリをリリースして設計や運用に関する多くの事を学んだので、その知見を共有します。
※当時の状況を説明しながら学んだことを書いていくので、結論だけ知りたい方はまとめをご覧ください。

想定する読者

この記事は、以下のような方々に向けた記事になります。

• これから個人開発を始めてみたいけど、どうやって進めたらよいかわからない
• サービスの運用経験がなくて個人開発の自信がない
• サービスを開発→リリース→運用するにあたって大切な事を学びたい

アプリを作ろうと思ったきっかけ

私は大学2年生までは、特にプログラミングが楽しいと思うわけでもなく、アルバイトやサークル、授業に取り組み、よくある大学生活を送っていました。
大学3年生から研究室配属があり、当時はHTML, CSSを用いてまともにウェブサイトすら作れないようなスペックだったので、自身の技術力に危機感を覚えていたこともあり、厳しいといわれていた研究室を志望し、そこに配属されました。

配属された研究室では、年中何かしらの開発イベントや勉強会が開催されていたので、取り合えず参加してみました。
参加したプロジェクトは学園祭に向けた展示用のシステムを作成するプロジェクトでした。
そこで、ほとんど先輩にフォローされながらでも、システムを完成させたときの達成感や、学園祭に来てくださった人々に展示物を使ってもらえることの喜びを覚え、システム開発が楽しいと感じました。

プロジェクトが無事に終了したところで、自分でも何か作ってみたい！と考え、趣味のツーリングをより楽しくできるものはないか、と考えた末に道の駅巡りアプリを作ることにしました。

アプリ開発を決心したときの筆者のスペック

• HTML, CSS, JavaScript, jQueryを使ってレスポンシブサイトの作成ができた
• Vue.jsを独学で学び始めて2カ月ほど
• Firebaseの存在は知っていた（使ったことはない）
• アプリ開発、リリースの知見ゼロ
• サービスの運用経験ゼロ

作成したアプリの概要

アプリの主な機能は、以下の通りです。
- 位置情報をもとに、道の駅に訪れたらスタンプを押せる機能
- 道の駅の訪問達成率をもとにしたランキング機能
- 一定の条件を満たすと獲得できるトロフィー機能

より詳しい機能についてはアプリページをご覧下さい。

ウェブアプリケーションで作ってみた

アプリ開発を決心した当初のスペックは、HTML, CSS, JavaScriptしか書けなかった為、ウェブアプリケーションとして作ることにしました。
バックエンド経験はゼロだったので、当時はまだ使ったことがないFirebaseを用いて開発することにしました。

わからないことばかりで何度も躓いては調べて、を繰り返し、ひとまずメイン機能である位置情報を元に道の駅を登録する機能が完成しました。

学び1：利用データの取得方法は設計時にはっきりとさせておく

この時点での学びとして、データを集めることの大変さを学びました。
作成する道の駅巡りアプリでは、位置情報をもとに道の駅の登録有効範囲かどうかを判定するため、日本全国道の駅の緯度経度が必要になります。
私は「このご時世だしインターネット上にデータが公開されているだろう」、と謎の自信を持っていましたが、そんなうまい話がある訳もなく、道の駅の緯度経度一覧は公開されていませんでした。

当時は日本全国道の駅の数は約1100駅（正確には覚えていませんが、1100駅は超えていました）ほどで、GoogleMapなどから道の駅の緯度経度情報を手動で調べるには時間がかかりすぎます。
アプリの機能を考えているときは、特にデータの取得方法などは考えずに、自分が欲しい機能だけを考えていたため、いざ作るとなったときにデータ集めがボトルネックになることを痛感しました。

以上の経験から、アプリ設計時には、利用したいデータを集めることが可能かどうかや、利用するデータの取得方法、を予め考えておく必要があることを学びました。

余談ですが、データの収集方法の1つにスクレイピングがあります。PythonならSeleniumが、JavaScriptならPuppeteerが有名でしょうか。
これらいずれかのライブラリを使えるようになっておくと、人生得する機会が多くなるかもしれません。

学び2：リリースするだけでは使われない（そもそも見つけられない）

紆余曲折ありましたが、時間をかけて道の駅のスタンプを押す機能と、達成率に応じたランキング機能が完成したところで、ウェブアプリケーションを公開しました。

Firebaseにホスティングして2カ月ほど経過しましたが、全く使われません。
それもそのはずで、SEO施策は行っておらず、Twitter等のSNSでの宣伝もしていない状態でしたので、使われるはずもありません。
唯一、数名の知人に使ってもらっていましたが、身内専用アプリと化していました(笑)

ここでの学びは、個人開発では、作ってリリースするだけではなく使ってもらうための施策が重要、ということです。
ウェブならSEO、アプリならASOをしっかりと考えないと、世の中に認知されないアプリケーションとなってしまいます。
こういうときにSNSのフォロワーがたくさんいると、一定数の方々に認知してもらうことができるので、SNSフォロワーはとても貴重な資産だということも実感しました。

学び3：維持費とモチベーションについて

ウェブアプリケーションとして公開したは良いものの、全く使われなければ話になりません。

ここで私はふと、維持費について考えました。
ウェブアプリケーションの一般的な維持費といえば、サーバ代とドメイン代ですね。

前者のサーバ代はFirebaseの太っ腹無料枠のおかげで0円です。
サービスローンチ時点で初速を出せない個人開発者にとって、この無料枠はとても大きな存在です。全く使われないアプリケーションに毎月少額でもお金を払い続けるのはモチベーション低下につながりますからね。

後者のドメイン代ですが、よくある〇〇.comを取ろうとすると大体月1,000円程度かかります。全く使われないアプリケーションに月1,000円支払い続けるのは、やはりモチベーションが続きません。
ウェブアプリケーションでは、ドメインを取らなければSEOの観点から不利とされていますが、ドメインを取ったからといって、一気にSEOが改善されるわけではありません。
SEOでは、サイトの被リンク数やコンテンツの質など、さまざまな条件が必要です。
もちろん広告費を払ってしまえばSEOは全て解決ですが、学生の私にそんな予算はありませんでした。

以上の経験から得た学びは、

• 使われないサービスにお金を払い続けると、金銭的な問題よりもモチベーション的な問題で続かない
• 使われるサービスにするためにはある程度お金が必要だが、お金をかけたからといって使われるとは限らない

モバイルアプリケーションに方向転換

ウェブアプリケーションとしてリリース後、サービスが使われない日々を過ごしながら、私はモバイルアプリケーションに方向転換することにしました。
もともと、道の駅まで行って登録する、というアプリの特性上スマートフォンでの利用をメインとしているため、ウェブよりもアプリのほうが使い勝手が良いです。（一応PWAにしていましたが、iOSユーザにはなんちゃってPWAしか提供できないのが辛かったです）
そこで、モバイルアプリケーションについて調べていると、どうやらウェブ技術でスマホアプリが作れるハイブリッドアプリなるものがあるようです。
しかも、ハイブリッドアプリはiOS, Androidにも対応可能です。
さらに、私はAndroidスマートフォンを使っているので、Google PalyStoreについて調べてみたところ、なんとアカウント登録時に$25支払うだけでその後はアプリをリリースし放題でした。
買い切り$25は、月額1,000円のドメイン費用と比べて格段にコストを抑えることができます。

ここで私はモバイルアプリケーションに方向転換することにしました。
ウェブアプリケーションで作った際にFirebase × JavaScript だとライフサイクルがないため、ユーザ認証が完了するまで特定のDOMをレンダリングしない、等の処理が面倒だったので、ライフサイクルがあるJavaScriptフレームワークを使うことにしました。
幸いハイブリッドアプリを作成するフレームワークであるCordovaは、モダンJavaScriptフレームワークであるReact, Vue.js, Angularのいずれもサポートしていました。
当時勉強中だったこともあり、Vue.js × Cordova で開発することにしました。
ウェブアプリケーションとしてリリースしていたソースコードを一部流用しつつ、ひたすら調べながら Vue.js × Cordova に作り変えました。

学び4：公式ドキュメントは絶対に読むべき

開発初心者あるあるだと思いますが、公式ドキュメントがわかりにくいor英語で読めないという理由から、Qiita等のやってみた記事をたくさん読んで解決方法を探していました。
そこで示されていた解決方法を実施してみても、うまく動きません。エラーメッセージでググってStackOverflowにたどり着いたり、かなり苦戦して開発をしていました。

これはCordovaに慣れてきた今だからわかることなのですが、当時のエラーは利用ライブラリのバージョンの違いによるビルドエラーや、旧バージョンでの解決方法を試していた等の失敗がほとんどでした。
Cordova は比較的古い技術なので、インターネット上には様々なバージョンのやってみた記事がたくさんあります。私は、自身が現在扱っているバージョンと異なるバージョンの解決策をひたすら探していたので、解決までにかなりの時間を要してしまいました。

以上の経験から得た学びは

• 公式ドキュメントは必ず最初に読む。よくわからなくても、他のやってみた系の記事を読んだあとに、再度公式ドキュメントを見るとわかるときがある
• どうしても公式ドキュメントの内容が分からない場合は、できるだけ最新のやってみた記事を参照する。その際、Google検索オプションを駆使してできるだけ目的にあった記事に絞込む
  • 2020年以前の記事： before:2020
  • 2019年以降の記事： after:2019
  • 特定のキーワードを除外： -除外キーワード
• 検索時は自分が利用しているライブラリのバージョンを意識する

ようやくリリース

モバイルアプリ移行に苦労しつつも、なんとか形にすることができたので、Google PalyStoreにリリースすることができました。
アプリストアにリリースすると、1日に1人～2人にインストールしてもらえました。ウェブアプリケーションとして公開した際は誰にも利用してもらえなかったので、毎日数人にインストールされている様子を眺めて喜んでいました。
その後は1日のインストール数が徐々に伸びていき、リリースして10カ月経った現在のインストール数は約2,000になりました。

学び5：データベース操作にクエリは必須

リリース後順調にユーザー数が増えてきて、300人程度になった辺りからアプリの動作が遅くなってきました。
原因はデータベースからの値の取得に時間がかかっていることでした。

初めてFirebaseを触った私は、「Firebase Firestore 値 取得」等で調べてたどり着いた公式ページや、やってみた記事を参考に、データベースからの値取得ロジックを実装していました。
イメージとしては以下のような状態です（経験のある方はこれはいかにヤバいコードかがわかると思います）

Firestore（DB）の構造

users: {
  ユーザID: {
    name: "山田太郎",
    その他ユーザ情報10件ほど
  },
  ユーザID: {
    name: "山田花子",
    その他ユーザ情報10件ほど
  },
  （以下、300件前後）
}

Firestoreの値取得

// アプリ起動時
const users = {}
const db = firebase.firestore()
db.collection("users").get()
.then(snapshot => {
  snapshot.forEach(doc => {
    users[doc.id] = doc.data()
  })
})

Firebaseについて詳しくない方向けに解説すると、アプリ起動時にデータベースに保存されているユーザー情報をすべて取得する処理です。

これだとユーザーが増えるたびにデータベースから取得するデータ量が増え、取得に時間がかかってしまいます。
開発経験のある方からすると、こんな当たり前のこと…と思われるかもしれませんが、当時学生の私にとって、これすらも考慮することができませんでした。

幸い、ユーザ情報に最終ログイン日時を持たせていたので、急遽ユーザー情報の取得を、
自身の最終ログイン日よりも後にログインしたユーザのみ取得し、端末に保存した全ユーザーデータを上書きする
という処理に修正しました。
つまり更新があったものだけを取得している状態です。
こうすることで、アプリの動作速度は無事に改善しました。

以上の経験から得た学びは

• 今後増えていくデータは必ずクエリによる差分取得が可能なデータ構造にする
  • 例）更新日や最終ログイン日などを持たせて差分取得可能にする

学び6：メンテナンスモードは必ず実装すべき

アプリはリリースして終わりという訳ではなく、機能追加や機能改善を行っていくと思います。
その際に出てくる問題の1つとして、DB構造が実現したい機能にあっていないことが挙げられます。
設計当初は想定していなかった機能追加や、DB設計がよくなかったのでDB構造を変更したい、といったシーンで困るのが、リリースタイミングです。

皆さんご存知の通り、モバイルアプリケーションは端末にインストールして利用するものです。
そのため、処理を変更した際はストアにアップデートを配信し、ユーザーにアプリをアップデートしてもらう必要があります。
仮にいくつかのバージョンが混在する状態でDB構造を変更すると、古いアプリバージョンの利用者は、過去のDB構造を参照しようとするので、DB構造を変更した時点でエラーとなってしまいます。
つまり、DB構造変更時はユーザーがアプリを使えなくする必要があります。

メンテナンスモードを実装することで、一時的にアプリを利用不可にし、DB構造を切り替えた後にアップデートを配信し、メンテナンス解除と同時にアプリのアップデートをユーザに促すことで、DB構造の切り替えを行うことができます。
また、DB構造を変更する際は旧バージョンのDB構造はそのままにし、新しいDB構造を追加してそちらを参照させることで、万が一旧バージョンを参照したユーザーが居ても、エラーを出さずに済みます。
さらに、新バージョンで問題があった際は、速やかに参照先を旧バージョンへ戻せばよいので、切り替えによって起きた予期せぬ不具合にも対応することができます。

以上の経験から得た学びは

• DB構造切替や予期せぬ不具合のために、メンテナンスモードは必ず実装する
• DB構造を切り替える際は、旧バージョンを残しつつ、新しいテーブル構造を作成すると良い
  • hoge/v1/fuga → hoge/v2/fuga や、 hoge1/fuga → hoge2/fuga といったように作ると切り替えがスムーズになる

学び7：そのデータはDBで持たせるべきか、ローカル（端末）で持たせるべきかを吟味する

次に値を保持する場所についてです。
当たり前ですが、DBを利用するには料金がかかります。
Firebaseであれば読み取り回数や書き込み回数、保存容量などで料金が発生します。
そのため、可能な限りDBで保持しなくても良いデータはローカルに持たせたいですよね。

私はリリースしたアプリでイベントを開催した際に、イベントで得たチケットの枚数をローカル（ユーザーのスマートフォン端末）に保存していました。
他のユーザーに獲得したチケット枚数を共有する訳でもなかったので、ローカルで保持しようと考えたからです。

ある時、ユーザーから「イベントチケットが消えてしまいました」とお問い合わせがありました。
そこで調査しようと思ったのですが、該当ユーザーのチケットの獲得状況はローカルで保持していたので、こちらから調べることができない状態でした。
システムエラーはログに出力するように設定していたのですが、該当ユーザーのエラーログは見当たらず、調査が難しい状況でした。
ユーザーとのやり取りの末、原因は2つのスマートフォンで1つのアカウントにログインしていたため、ローカル（端末）に保存していたチケットの枚数が共有されなかったことだとわかりました。

DBで保持しなくても良いデータとは

以上の経験から、私は、以下のいずれも満たさないものが、DBで保持しなくても良いデータだと考えています。
※これはアプリの特徴や人によって考え方が変わってくるところだと思うので、あくまで一個人の意見として見て頂けると幸いです。

• 他のユーザに共有する可能性があるデータ
  • 例）道の駅の訪問達成率、ユーザー名などのプロフィール情報、アイコン画像
• 不具合が発生した際に、調査に必要なデータ
  • 例）ログイン日時、フレンド申請状態管理データ、イベントやランキングスコア
• 複数のスマートフォンで同一アカウントにログインした際に、データの差異が発生する可能性があるデータかつ、差異が生じた際に不都合があるデータ
  • 例）イベントやランキングスコア、ユーザのフレンド情報

上記を満たさなければ、ローカルにのみ保存して良いデータだと私は考えています。
上記のルールを満たさないデータの具体例を考えてみると、以下のようなデータが挙げられます

• お知らせの既読、未読情報
• アプリのUIカスタマイズ機能
  • テーマカラー、フォントサイズなど
• チャットメッセージの既読、未読情報
• 表示速度高速化のためにキャッシュデータ

学び8：エラーログに含めるべき情報

アプリ開発に限らず、サービスにはバグがつきものです。バグが起こらないシステムなどありません。
そこで大切なのが、バグが起きた際にいかに速やかに原因を突き止め、解決するか、です。

以前、ユーザーから「アプリが起動できません」とお問い合わせがきました。
これだけでは、どういった状況でアプリが起動できないのか、起動できないというのはスプラッシュスクリーン（アプリの起動画面）が表示されないのか、スプラッシュスクリーンは表示されるが、その後のページがロードされないのか、等考えられる可能性は無数にあります。
また、手元の環境でエラーを再現したいのですが、該当ユーザーがどのバージョンを利用しているのか、機種やOSは何か、などあまりにも情報が不足していて、再現が難しい状況でした。
当時はシステムのエラーログのみを出力していたので、ユーザーのとやり取りで機種名やOSのバージョン、アプリのバージョンなど、様々な情報をヒアリングしました。
結果的に無事に解決することができたのですが、解決までに数日を要してしまい、ユーザーに迷惑をかけてしまいました。

以上の経験から得た学びは、エラーログには、最低限以下の情報を出力すべきだと考えています。

• ユーザID
• アプリバージョン
• 端末情報（OS、機種など）
• エラー発生時刻
• エラーメッセージ
• その他、エラー発生時特有の情報
  • 例）エラーが発生した際の変数の中身、どこまで処理が進んで、どこで不具合が発生したか、など

学び9：開発環境と本番環境のデータ量は同じにする

ユーザー数も順調に増え、本番環境で機能開発をするのが怖くなってきたので、開発環境を作りました（本来は初めから用意しておくべきですが……）
開発環境を作成してからは、開発環境をメインに機能開発や修正を行い、問題がなければ本番環境にリリース、という流れで開発を行っていました。

ある日、いつものように開発環境での動作確認は問題なかったので、本番環境にリリースしました。
すると、開発環境ではうまくいった処理が、本番環境だとうまくいかない、という事態が発生しました。

どうしてこのような事態になってしまったかというと、原因は開発環境と本番環境のデータ量の違いにありました。
本番環境では日々ユーザーが増え、ユーザー数が1,000人ほど居ましたが、私が用意した開発環境はユーザー数が15人ほどしか登録されていませんでした。
ユーザー数増加に伴い、処理に時間がかかり、開発環境ではうまくいっていた非同期処理が、本番環境では実行時間の増加によりタイミングがずれてしまいました。

以上の経験から得た学びは、開発環境と本番環境のデータ量、データの種類は同じにするということです。

学び10：リリースタイミングはよく考える

個人開発者の方は、日々隙間時間を見つけて開発をしていると思います。
ひたすら開発を続けている人も居るかもしれませんが、それでも1泊2日の旅行にいったり、24時間以上開発ができない状況になることはあると思います。

私がリリースしたアプリは、実際に道の駅に訪れて登録する、という特性上、1週間のうちに土日で最も利用されます。
幸いFirebaseはオートスケーリングなどは勝手にやってくれるので、こちら側が管理する必要はありません。

私はとある金曜日に新機能をリリースをしたのですが、次の日から1泊2日の旅行の予定がありました。
というのも、新機能を自ら使ってみようと考えていたからです。
新機能の動作確認も問題なかったので、後日リリースした機能を使って楽しくツーリングをしていました。
すると、ユーザーからのお問い合わせでランキングの変動がされなくなっていることが発覚しました。
原因を探して修正したくても、1泊2日のツーリング真っただ中のため、PCもなければ帰宅するにも宿を予約しています。
仕方なくユーザーからのお問い合わせには、数日後に対応したのですが、お問い合わせがあった瞬間から楽しいツーリング中でもお問い合わせの内容が頭から離れませんでした。

以上の経験から得た学びは、リリースタイミングはよく考えるということです。
どんなにテストをしたとしても、予期せぬ処理にバグが発生することもあります。なのでリリース時は、リリース後数日はバグが起きてもすぐに直せるような状況を作ってからリリースすると良いと思います。

まとめ

学生時代に初めてアプリをリリースして学んだこと10選のまとめです。

• 利用データの取得方法は設計時にはっきりとさせておく
  • アプリ設計時には、利用したいデータを集めることが可能か、利用するデータの取得方法、を予め考えておく
• リリースするだけでは使われない（そもそも見つけられない）
  • 個人開発では、作ってリリースするだけではなく、使ってもらうための施策が重要
• 維持費とモチベーションについて
  • 使われないサービスにお金を払い続けると、金銭的な問題よりもモチベーション的な問題で続かない
• 公式ドキュメントは絶対に読むべき
  • やってみた系の記事はわかりやすいが、バージョンの違いによって動かなくなることが多々あるので、公式ドキュメントは必ず最初に読む。よくわからなくても、他のやってみた系の記事を読んだあとに、再度公式ドキュメントを見るとわかるときがある
• データベース操作にクエリは必須
  • 今後増えていくデータは必ずクエリによる差分取得が可能なデータ構造にする
• メンテナンスモードは必ず実装すべき
  • DB構造切り替え作業や予期せぬ不具合への対策として、メンテナンスモードは必ず実装する
  • DB構造を切り替える際は、旧バージョンを残しつつ、新しいテーブル構造を作成すると良い
• そのデータはDBで持たせるべきか、ローカル（端末）で持たせるべきかを吟味する
• エラーログに含めるべき情報を考える
  • ユーザID
  • アプリバージョン
  • 端末情報（OS、機種など）
  • エラー発生時刻
  • エラーメッセージ
  • その他、エラー発生時特有の情報
• 開発環境と本番環境のデータ量は同じにする
• リリースタイミングはよく考える
  • リリース時は特に、リリース後数日はバグが起きてもすぐに直せるような状況を作ると良い

以上が私が学生時代に初めてアプリをリリースして学んだこと10選でした。
経験を積んだエンジニアの方々からすると、どれも当たり前の内容かもしれませんが、これから個人開発を始める方など、開発経験の少ない方のお役に立てば幸いです。
読んでいただき、ありがとうございました。

言語化するために記事に起こしました。
汎用性の高いスターターテンプレートで雛形を作成するまでを簡潔に記します。

事前準備

①Node.jsの導入
②Yarnの導入
③direnvの導入

①、②共にNuxt.jsで開発する上で必須となるので導入する（ここではこれらの導入方法については省略します)。

③はターミナルのcurrentディレクトリで環境変数を自動で設定してくれるツール。環境変数の設定忘れを防止するため導入するとよい。

1

ターミナル

npm i -g @vue/cli @vue/cli-init

上記コマンドで、Vueコマンドを追加する。「Vue -V」でバージョン確認。

ターミナル

$ vue -V
  @vue/cli 4.5.9

2

1により、「vue init」コマンドでプロジェクト作成可能。
今回は初学者やカスタマイズして利用したい方におすすめのテンプレートである、「my-first-nuxt-app」を利用する。

desktop

$ vue init nuxt-community/starter-template my-first-nuxt-app

インストール中のいくつかの質問は全てEnterでOK。
作成後、

ターミナル

$ cd my-first-nuxt-app #ディレクトリに移動
$ yarn #パッケージをインストール
$ yarn dev # 開発モードでプロジェクトを起動

OPEN http://localhost:3000
と表示後、上記URLにアクセスする。

3

このような表示が出れば完了です！