Firebaseを使用したプロジェクトのデプロイ先変更を行う

既存のプロジェクトと同じ構成(自分はvue)の開発を進めたい時、
cloneしてきたプロジェクトのデプロイ先は以前設定していた箇所となっているため、
firebase initした後firebase deployを実施してもデプロイ先は動的に変更されない。

※cloneしてきたディレクトリ名やmain.js等で指定したFirebase SDK snippet等の
 認証を勝手に読んでデプロイ先を変更してくれる等の機能はなく、デプロイ先変更コマンドとして
 明示的に変更して上げる必要がある(SDKはあくまで認証時にのみ使用されるため)

結論: firebase use (ProjectID) を使用することでデプロイ先を変更する

git clone https://github.com/xxxxxxxx/yyyyyyyy.git

// 任意の方法で新規プロジェクト名:zzzzzzzにリネームを実施

firebase use zzzzzz
firebase deploy  // zzzzzzにデプロイが実施される 

実行結果

注意:firebaseのデプロイ先を変更してもFirebaseSDKの設定は動的に変わらないため
   認証等を使用する場合新しく作成したプロジェクトの情報を新しく登録する必要あり。
   (※で書いている内容の逆:Firebase機能が使えるかは別途確認すること)

個人開発のマネタイズを見据えた開発方針について

個人開発の方向性としてよく見られるものについてまとめと今後目指すべき所のメモ的なまとめ

各項目ともAが一番難しい・大変なものになり、正直全部Aの物を開発するなら
企業等で取り組むレベルなのでどこで妥協できるかを見ながら作る方向性を決める必要がある。

1.作成する開発物の形態は?(マルチ向け?ソロ向け?)

・A.プラットフォーム型

・B.ツール型

→プラットフォーム型(PF型)は投稿であったりユーザーの参加であったりツール型よりも
集客が難しいので全体で一番難易度が高くなる。(ツールはニーズに沿っていれば使われるため)

個人でPF型の開発をする場合、以下の内容が重要なため覚悟をして挑むこと。

・ツイッター等情報発信できる環境で発言範囲を広げておく
・対象となるカテゴリのコミュニティで宣伝を行う
・常に集客を考えるようPDCAを回す

2.機能の幅はどれくらいか?

・A.多機能

・B.単機能

→工数に直接影響する。多機能なものも実際分析してみたらあまり使われない機能があるということや
後で欲しくなった機能を結局実装する時間がかかる(優先度付けが甘い)ということも考えられるので
分析して必要のないものを削ったり、マイクロな範囲でスタートすることも検討する。

3.アプリはどのデバイスでの使用を想定するか?

・A.スマホアプリ

・B.Webアプリ

→どちらも既存の技術スタックがあればあまり差はないが、スマホの場合iOSとAndroidで
差が出てくるため少し難易度が高い。後述のマネタイズ関連の実装をする際スマホアプリであれば
買い切り型をそのままストアに収益部分を任せることができるため便利になる部分もある。

Webアプリで買い切り等の課金を実施する場合、カード情報等を使用する可能性があるため
セキュリティ意識を一段上げる必要がありあまりオススメしない。
OSアプデで使えなくなる等の不具合も考えられるため、サポートに割くパワーは少し大きくなる。

※Webサロン等でpaypal送金等で集金化しているところもあるが、使用開始前の手間が増える
→面倒だからいいやという考え方になり、本来獲得できるユーザーも離れる可能性がある

4.使用者はどの層をターゲットにするか?

・A.一般層

・B.SNSが使用できる一般層

・C.ネットリテラシー・インターネット力が高い層

テックブックランキングのようにうまく範囲を絞ったサービスであればバック側では
最低限の情報を持てば良く、特にボタンの説明等がなくても使い方を勝手に理解し、
ときには改善点を指摘してくれたりとユーザーが少なくてもフィードバックが受けやすい。

次の段階として少なくともSNSが使用できる層に対し、カテゴリ分析した上でターゲティングする。
サービスが良いものであれば感想や情報をSNSで共有してくれたりするのでメリットも大きい。

5.マネタイズ方式は?

・A.サブスクリプション型

・B.買い切り型

・C.アフリエイト型

・D.アドセンス型

→サブスク型は世の中のサービスの相場観を考えると月数百円でも相当なレベルを要求されるため、
需要を分析した上で展開しないと工数使ったけど失敗、という可能性も大きくなる。

買い切り型であれば1度のために決済関連を実装するのは手間なので、二の足を踏ませないかつ
セキュリティ的に難易度が下がるよう外部のサービス等を使用した方式についても考える。

また、規約等がないと「お金を払って使っていたのにサービス終了して逃げられた」みたいな
トラブルも考えられるので、うまく考えてサービスを運営する必要が出てくる。

※正直当記事でここが一番言いたかった(気になった)所。あくまで主観的ではあるがスマホアプリの
開発(OSサポート)終了していることはよく経験していても有料Webアプリがサービス終了する
経験はほぼほぼ無いため、スマホアプリでは存在しない未知のトラブルも考えられる。
(スマホは明確にOSアップデートでサービス終了と言うのも手だが、Webだと線引ができないので)

6.サービス開発の目的は?

・A.勉強用

・B.ポートフォリオ用

・C.マネタイズ用

→技術を身につけるために個人開発をするとどうしても普通の開発よりもスピードが落ちるため、
マネタイズ用と言っているがアドセンス等を使う方式であればリクルーターをターゲットとした
ポートフォリオ開発よりもハードルが低い可能性も十分ある。(単機能ツールとかの場合)
1~5が決まっていれば6は特に決めることは無いと思うが、意識としてブラさないようにする。

その他重要なこと

・開発期間を先に定める(分析期間も含めておく)
・類似サービスはしっかりと見ておく

自分の中での結論

1.勉強的意識が5-6割存在しているがマネタイズもしたいため、ツール系サービスをSPAで開発する。
2.ツールは多機能である必要がないので、カスタマイズ等含めて2-3用途くらいあれば十分。
3.vue+node+firebase(必要?)くらいのイメージなのでWebアプリとして開発する。
4.ユーザーをある程度増やしたいのでSNS使用できる一般層からターゲティングする
5.リスクが低めなアドセンス方式で、商品が絡む場合アフリエイトも入れる。
6.マネタイズがメイン。SPAは機能として使うため少し勉強する。

JavaScriptでobjectを利用し関数を部品として使用する

JavaScriptで複数のモジュールを組み合わせて使用しており、設計上の理由で変数を
特定のモジュールに入れないといけないが、メインモジュールからそのモジュールを参照すると
変数がクロージャのためundefinedになってしまう事をケアするためclassを使用せず、
オブジェクト形式で式と変数を持つ形で実装したときのメモ

モジュールがclassになっているといい所
・継承ができる
・名付けにより用途がわかりやすくなる
・様々な構造があるオブジェクト形式と違い、コンストラクタ等の記述を見ればある程度
 情報が理解できるため新しくコードを見た人にも分かりやすい

モジュールがObjectになっているといいところ
・実装が楽
・変数が増えれば増えるほど複雑になりがち
・構造が独自になるので再利用が難しい

ある程度開発に慣れてくるとモジュール=classみたいな考え方になってしまい、
簡易的な構造の処理が外出ししたいときでも記述量が多くなってしまう。
そのため開発速度が遅くなるよりはオブジェクト形式で実装した方が早いという判断。

// 計算用のモジュールをいくつか入れる
const parts = {
  binaryFlag: true,
  hexadecimalFlag: false,

  // 1回実行毎に2進数と16進数を切り替える
  changeType : () => {
    if(binaryFlag === 'true') {
      binaryFlag = false
      hexadecimalFlag = true
    }else{
      binaryFlag = true
      hexadecimalFlag = false
    }
  },

  changeDecimalToOtherType : (num) => {
    if(binaryFlag === 'true') num.toString(2)
    else num.toString(16)
  }
}

1モジュール内にフラグをもたせて外部からparts.changeType()を実行し、フラグ切り替えの構造で
実装を行った。モジュールロード時にparts.changeDecimalToOtherType(10)を実行した場合、
binaryでの変換が実行されるため10 = 1010となり、parts.changeType()実行でhexadecimalFlagが
trueとなるため10 = Aの実行結果が表示される。

基本的には継承・可読性・インスタンス化を考えるとclassを使用したいけどサクッと書けるので
選択肢として持っておきたい。