• 2020.12.01

自分がReactを選ぶべきだと思うただ1つの理由

今後何を勉強するかを分析して、対応幅が広くなりそうなReactをやろうと思った。
Vueと同じくフレームワークだったりCliツールだったり色々あるので、React内の各ツールとVueの現状を比較しながらReactをやろうという方向に考えを持っていくために色々調べてみることにした。

React

Vueと比べてJavaScriptがメインの開発であるため、初学者が取り組む場合JavaScript学習から始める必要がある。(非同期、イベント駆動、基本的なESバージョン差の吸収ができないと厳しいかも)
学習コストが高い以外、特に弱点みたいなものはない印象。

Reactを使うデメリット(ちょっと古めの記事)から見ても、Reactの問題というよりは当時導入事例が少なかった事が大きいので、現在の知見量がありNode.jsが書ける人は抵抗なく入れると思われる。

開発する場合CRA(create-react-app)によるプロジェクト生成・Next.js(フレームワーク)他ボイラープレートを使用した環境構築をすることになるが、CRAだとクライアントサイドでのレンダリングが基本になりSEOの面で弱いため、Nextを使用してSSR(Server Side Rendering)またはSSG(Static Site Genelator)によりSEOに強いサイトを作成することが一般的。

CRAはNextにある機能を後で導入したくなった場合カスタマイズが面倒だったり、実運用に必要な機能は要拡張だったりするので、手軽に・かつSEOを気にしない機能を作る場合以外のプロジェクトであまりおすすめできない印象がある。

・特に抵抗ないならNextを使っとこう
・TypeScript学習をしておくと最新フロントエンド環境に追いつける

参考リンク
Next.jsの特徴と採用するメリットについて考えてみた
Next.js 4年目の知見：SSRはもう古い、VercelにAPIサーバを置くな：機能レベルの知識視点。
なぜNext.jsを採用するのか？：CRAとNext.jsの比較
CRA (Create React App), Next.JS, Gatsby【 どう使い分けるのか？】

Vue.js


Reactと比べて単一コンポーネントにhtml/css/JavaScriptが纏まっている。そのため機能が分割されておりシンプルなコードにしやすく理解が楽になる。

またTypeScriptとの相性があまり良くない。クリティカルに言及している記事はないっぽいけど、
お悩み相談の記事に書いてある事・2019年版Vue.jsTipsから解釈すると、Vue.js自体JavaScriptが動的であることを生かしたフレームワークであるため、型が発生することで本来存在していない要対応の問題が出てきてしまう問題はあると思う。

使用するボイラープレートによっては上の限りではないけど、はじめからどっちでも良いのであればわざわざ問題を抱える必要がないと判断し公式導入できるReact + TypeScriptにシフトするプロジェクトが多い気はする。

加えて、Tips記事へのリアクションでも多く見られる「Vuexを入れるならNuxt以外のフレームワークを使うべき」という部分と「大規模になるならVuexを入れたほうがいい」という考え方が競合するので個人勉強レベルで「なんとなく入れてみたorなんとなく入れなかった」で学習難度に差が出るのも気になった。

・初学者が集まるプロジェクトならVueの方が楽。2が主流だがVue-Cli3の発展に期待。
・Vuexが曲者。導入する場合は上と異なり分かる人がいないときつくなりそうなイメージ

参考リンク
【Vue.js】vue-cliとNuxt.jsの比較まとめ：自動ルーティングの有無、状態管理の有無
Nuxt.jsに飛びつく前に~Nuxt.jsを習得するための前提技術と、その勉強方法の紹介~
2019年版Vue.jsを使ってる人には必ず知っていてほしいVue.jsの武器とドキュメントに書かれていないコンポーネントやメンテナンスの際に役立つTips
【Vue.js】Vuexの「状態管理」はいったい何の状態を管理しているのか調べた
開発はVue.jsでしたいけど、TypeScriptを入れたい問題をどうするかフロントエンド開発のお悩み相談

採用事例系

Vueはフロントエンドエンジニアが多い企業(特にWebデザイナー・コーダー)で導入されることが多く、動きが多くなったり連携するモジュールが多くなりそうな場合はReactを採用している会社が多い印象を受けた。

DMM採用事例2018：基本Nuxt、Nextも使ってみているためどっちでもという感じではある
Yahoo採用事例2018：Nextが多い
Next採用事例まとめ：参考程度。大手でも結構使ってるよ、的な
ホットペッパービューティーコスメ：チャレンジ気味なAMP開発でVueなくReactを選んだ

結論

・小中規模のプロジェクトの場合ほぼ差は出ない。メンバーの習熟度を見て選択する。
・React→大規模になると状態管理的に優勢。React Nativeを勉強すればスマホアプリも作れる。
・Vue→学習コストが低いので小規模で収まることが確実なら工数少なくできる。Vuexが辛い。

大規模なプロジェクトの採用シェアが高く、小中規模の差が出にくいのでちょっと遠回りしてもJavaScriptを学ぶ→Reactを勉強する方向が一番メリットが大きそう。Node.jsにも発展できればAPIもかけてほぼなんでも作れるようになるので、案件に配属される予定があるのであればVue、個人開発or学習目線で実施するならReactが良いと思う。

学習レベルは上の通り、プロジェクトにおいてはVuexを使う場合工数かければ頑張ってできないことはないと思うのでReact-TypeScriptの採用知見がとても多い事が一番のReact採用理由だと思う。

その他

あらためてReactとVueを比較してみる〔2020年最新版〕
React（Web）とReact Native（with expo）の同じところ違うところ

  • 2020.11.27

2020年最新技術とそれに関する知見

最近Twitterで流れてきて気になった単語。
単語レベルではすべてシェアがフラットに見えるので、Qiitaの直近一ヶ月記事件数がどれくらいか？
というある程度意味のある観点で調べてみて将来的にどうなのか、触れるべきかどうかを考える。

2020/10/23-11/23の記事数を表示。

Flutter


Qiita投稿記事　103件

iOSとAndroidに対して同じコードでアプリを開発できるフレームワーク。
JavaScriptに似たDart言語での開発となる。JavaScriptとの違いはこちら(Quora)参照。

乱暴に言うとTypeScriptの書き方が違うモノ。TypeScriptよりユーザーが少ないので情報が得辛い。
めちゃくちゃ変わるわけではないので学習コストはそこまで高くないが、JavaScriptだけで
iOS/Android開発に対応できるReact Nativeと比べて以下の問題がある。

・採用事例がReact Nativeに対し極端に少ないこと
・Dartを覚えてもここでしか使うことがないため、TypeScriptを導入したReact Nativeと
　比較すると学習効率が悪くなる

※ReactNative採用事例としてFacebookやInstagram、Airbnb等のビッグネームがあるが、
　FlutterはGoogle以外大手企業での採用事例が少ない。

　参考：モバイルアプリ開発にGoogleのFlutterを使うべき8つの理由

感想
・Flutterの方がコンパイルが早いらしいのでデカくなればなるほど有利かも
・単純な案件数で見たとき少ないので、覚えてもそのまま使わない可能性も大
・採用する案件があったら飛びついて中で勉強させてもらうのはめちゃくちゃ有意義だと思う

Glide


Qiita投稿記事　6件

NoCode開発ツール。GoogleSpreadSheetをデータベースのように使ってwebアプリを作成可。
GUI操作だけでそれっぽいものが作れるので、構築すればメンテナンス等を企業側ができ
自社内で使う情報ポータル等を作ってるような採用事例はあるらしい。社内SEなら出番あるかも

参考：非エンジニアでもできる Glide を使った PWA アプリ開発

感想
・情報表示系ならデバッグ等なしでできそうなので、データを表示してアクセス稼ぐページを作る場合
　DB構築等が必要ないため開発コストをかなり少なくできる(スクレイピングとの相性が良いかも)
・用途が明確でない限りコード書ける人間がわざわざ触る意味はあまりない。

React / Vue


React Qiita投稿記事　349件
Vue Qiita投稿記事　395件

VueもReactも現在ではフロントエンドフレームワークとしてかなり使われており、
Angularと比べて比較的規模感の小さい現場でも導入されていること・マイクロサービスと
GOの流行感からフロントエンドをやっていこうとすれば避けて通れなさそうな技術になっている。

複雑な処理でなければバックエンドはFirebaseや各企業が提供しているAPIでなんとかなるため、
個人開発をやりたい場合Vue/Reactさえわかっていれば開発工数を大きく減らすことができ大変便利。
両者ともSSR / SPA対応できるので、チームのJavaScriptレベルでどちらか選定する感じになりそう。

※以下、Vueはハンズオン程度の知識、Reactは調査レベルの知識前提になります

Vue.js

Vueはcomponent単位でhtml/JavaScript/CSSが一つになった.vueファイルが作られ、
1ページ1ページの処理・コンテンツをまとめて管理できるので開発者が少ない環境であれば
ファイル移動が少なくシームレスな開発ができそうな感じで良かったと思う。

ただ記法が混ざった.vueファイルが結構癖があって、lintがうまく動かなかったり
Vueはv-model・v-for等データのバインディングがVueのネイティブ機能で存在しているため
独自記法になれるまでは多少つらい感じだった。

加えてVueについてはBootStrapのようにパーツ的に扱える素のVue、
かなり使われているVue CLI2と2018年8月ごろに出たVue CLI3があり、区別する必要がある。
CLI3ではCLI2で使えていた外部ツールがまだ対応していない、記法が変わっているなど
ネット上QAも使っているCLIバージョンに対応しているか注意深く見る必要があり、
超大手が使っているReactと比べると情報の取捨選択は難しくなるかなと思う。

Nuxt(大規模には向いてるが設定が増える)とかVuetify(途中導入するとバージョン違いでコケる)等
開発パターンにも差があるので1個に入れ込みすぎると現場で全く使わなかった、的な事はあるかも。

Vueのまとめ

・component単位で書けるためファイル移動が少なく開発できて楽
・.vueファイルが独自記法のため癖があってなれるまで難しい
・素Vue/Cli2/Cli3の差がデカく、情報の正確な取捨選択が必要
・触った感としてバージョン差異は少し大変だけど全体的にシームレスな開発の楽さが大きかった。

React

FaceBook等大手が使っているフロントエンドフレームワーク。
.vueのような形ではなくJSX記法を用いてJavaScriptでhtmlを出力していく方式。

あまり意識せずにvueを勉強していたが、Reactの記法を見ているとかなりJavaScriptに寄っており
めちゃくちゃ開発しやすそうなので、先に知っていたらReactから手を付けてたかもしれない。

VueはJava開発をしていたときのJQueryに持っていたイメージと近く、JavaScriptの知識が少なくても
ドキュメントを読み込めばサクサク進める感じだったが、ReactについてはJavaScript的な書き方が
必須となるためある程度知識がある前提ならReactの方が発展性があるように感じた。
(vueだと.vue由来のよくわからないエラーとなるが、ReactだとJSエラーとして解決できるため)

ReactにもReact NativeやNext等のフレームワークがあるため現場での差異吸収は必要だと思うが、
トータルの知識をJavaScriptレベルに集約できそうなので、勉強のしがいはかなりありそうだった。

※余談レベルだがLineの開発者LTで、現在のデファクトはReact + TypeScriptという話が出ていたため
　この組み合わせの開発経験については知見もしっかりしておりかなり将来に有利に働くと思う。

Reactのまとめ

・JavaScript/node的書き方がわかる前提になるが、汎用性・発展性は高そう
・React/ReactNativeの差は未確認だがJSベースなので必要以上の心配はいらなさそう
・これからはTypeScript前提になってくるかも

Docker


Qiita投稿記事　675件

仮想化ツール。2020 lateのMacBookで使えない(新OSのせい？)事が話題(2020/11現在)
もう流石にモダン開発では必須、常用してない会社に在籍するのは考えるべきだと思う。
AWS、GCPともにコンテナ運用が主流になっているので、Docker Hubにアップされている
イメージの組み合わせだけでいろいろな環境を構築できて便利。

Dockerについては使ってる企業と使ってない企業では年収100万前後変わってくるイメージなので
もしSES系企業から転職する場合は一つのラインとして考えてもいいと思う。

※転職先の技術判断に関して、AWSに関しては準レガシーくらいな企業でも本番用として
　「ある程度シニアな社員が」使っていたり、各種フレームワークについては相手としている業界で
　使われているモノが変わってくるため、会社の技術レベルが図りにくい。
　特に前者は入っても自分がAWSを触れなかったり、シニア社員は残業代で給与が高くなっているため
　必然的に社内の労働時間が長め、ということがあり得る。(あくまで経験談)
　社員が全員Dockerを使っている環境は比較的貸与PCのスペックも高く、ECS常用しているケースが
　考えれられるため、スキルレベルの平均値も高く比例して年収も高くなると思われる。

感想
・検索件数のベンチマーク的に使用、やはり今では仮想環境の必須知識なのでもう少し慣れたい
・運用自体は問題ないが構築に対するスキルが今一つのため今後一番身につけたい所
・もう少し個人開発に使っていきたい所はある

GraphQL


Qiita投稿記事　46件

API用に使用するクエリ言語。QL=クエリ言語なのでSQLのWeb版だと考えると理解しやすい。
RESTApiだと削除はdelete、登録はget/post 等エンドポイントが複数になることに対して、
GraphQLはエンドポイントを一つにし、飛んできたリクエストをクエリにて処理しJSON返却する。

エンドポイントが増えないため、エンドポイント仕様策定に余分な工数を使ったり
実装後メンバー間でエンドポイントの仕様差が出てきてしまう等の問題をケアできる。
(getで登録処理を書いているメンバーがいたり、postで登録処理を書いているメンバーがいたり、等)

ネット上知見が少ないことに加え、以下の問題点が存在する。
・複雑なクエリになると実装が難しかったりエンドポイントが一つのため分析が難しい
・RESTのHTTPエラーが戻ってくる形と異なり検索ができてしまえば200が戻るため結果解析が必要
・ライブラリがそこまで充実しているわけではないので、連携する機能によっては実装が面倒になる

参考：Web API初心者と学ぶGraphQL
　　　初心者目線でGraphQLを解説！～同じWebAPIのRESTとの違いは？～
　　　「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ

感想
・乗り換える場合ライブラリ等を考えるとコスト感が高そうで面倒かも、フルスクラッチならあり？
・よっぽど理由がなければRESTが採用されそう。Flutter(≒Dart)に考え方は似てるかも

Electron


Qiita投稿記事　33件

JavaScriptでデスクトップアプリを作れるフレームワーク。
採用事例はSlack、Visual Studio Code等。
JavaScriptでフロント、サーバーサードはできるけどデスクトップアプリは作れないのかな？と思って
調べたらElectronがあった。以前はWindowsアプリ開発用に別のツール的な物があったらしい。

QiitaのSlack開発環境分析を見る限り、バックエンドさえ組めればある程度の物が作れそう。
デスクトップアプリにする必要があるか？(広告収入は？セキュリティは？等の問題があるので)を
考え、スタンドアロンで動かす必要がある場合はElectronを勉強する選択肢もいいかなと思った。

ただ他デスクトップツールやデバイスと連携したいみたいなことがなければWebアプリor
React Nativeで足りるため、個人開発レベルの優先度としては低くてもいいかな、と思った。

参考：ようこそ！Electron入門

感想
・フロントpureJS、バックエンドnodeでも開発できそうなので、ツール開発したいなら便利かも
・といってもFlutter等の選択肢もあるので、参画する可能性がある案件次第で判断したい。

JavaScript

Qiita投稿記事　1207件

現在のメイン言語、使ってるとフロント～バックまで触れて最強感がある。
後述のQiitaタグ検索でも件数は圧倒的であり、廃れるにしても代替言語が熟れない限り
フロントエンドとしては一択なのである程度延命できると思う。

処理速度が他言語と比べて遅めな事、静的型付けではないことからバックエンド処理としては
他言語が採用されることも多いため、逆発想としてnodeを使用している案件はモダンなケースが多い

バックエンド処理については各企業ものAPIを使うことである程度吸収できるので、
expressとかnodeが使えればある程度何でもできるようになる。

将来的観点としてTypeScriptがよりシェアが増えたときに乗り換えできるように勉強したり、
GO等実行速度の早い言語を勉強して案件の幅を広げていくことが重要かなと思う。

ex.言語別(タグで検索)

メイン使用言語

JavaScript Qiita投稿記事　745件
TypeScript Qiita投稿記事　173件

将来触れる可能性のある言語

Python Qiita投稿記事　981件
Go Qiita投稿記事　107件
kotlin Qiita投稿記事　108件

触れる予定は無いがウォッチすべき言語

Ruby Qiita投稿記事　691件
PHP Qiita投稿記事　378件
Java Qiita投稿記事　297件
C# Qiita投稿記事　191件

言語利用シェアでもほんの参考程度にしかならないため感想は列挙のみとする。
・JavaScriptはnode/vue/react等に吸われているのかフロント・サーバーサイドと
　両方が使用可能にも関わらず思ったより多くなかった。
・新しい言語は記事数を見て流行っていないと捉えるか？「流行りの走り」段階と捉えるか？
　数字の推移だけでなく採用事例をみて注視していく必要がある。
・Pythonが非常に多いが機械学習系モジュール開発などPython案件のレベルは高くなる傾向にある
　＝小手先で勉強しても太刀打ちできないのでは？感がある
・気になっているのはGO、新規言語を覚えるなら採用事例を見つつ第一選択肢として考える？

全体感想

ストレートに勉強して利がありそうなのは以下項目
・React + TypeScriptの開発環境(個人開発目線)
・React Nativeでのスマホアプリ作成
・Docker + AWSの「現場開発レベルを想定した」環境構築
・GO(項目としては割愛したが調査も含めて)

Flitter / Electron / React Nativeについては選択になるが、前2個は独自の考え方となってくるので
調べたら技術シェア的に個人レベルで勉強するメリットが薄く感じた。

文字でまとめると方針も正確になるため、トレンド変化したタイミングでまた分析してみようと思う。

とりあえずQiitaセールでReactの講座を買った！

  • 2020.11.19

[JavaScript]なろうのランキングをAPIで一括取得する

APIが使える環境があり、定期的にそれを使っているならちょっとコード化するだけで
やりたいことが数秒短縮できる、みたいな記事です。

やろうと思った経緯

夏頃ステイホームの暇さに煽られ、kindlePaperWhiteを購入しました。
暇つぶしに「小説家になろう」を読み続け数ヶ月、有名所を読み終えたため
まだ見ぬ掘り出しモノを探すためランキングをローラーするようになりました。

何度もサイトにアクセスしているため、いちいちアクセスするのが面倒になったのと
(**単純にランキングが多少見にくいみたいなところもある**)
現プロジェクトで使っているAPIのcall側が複雑で分かりにくいスパゲッティ実装であり
復習を兼ねてかんたんな実装を試してみたかったため、
見たいランキングだけnodeで取得してtext化するモジュールを作成しました。

やりたいこと

①パラメータ設定済みのAPIを叩きJSONを取得
②適当なファイルに出力

APIを叩きJSONを取得

rpmのrequestを入れて完成まで行ったのですがrequestは今年の2月頃から非推奨のため
axiosに変更しました。request使用が簡単すぎたので大丈夫かな？と思ったのですが
使ってみたら現場と同じだったり、Promiseだけでほぼ差異はありませんでした。

適当なファイルに出力

今回はcli出力だと見辛いかな？程度の文字数だけどリッチに見せたいような事もないので
簡易的にtextで出力するようにしました。

実装

ソース：https://github.com/sena-v/narouRankingToText


const axiosBase = require('axios') // ①に使用
const fs = require("fs"); // ②に使用

// urlと検索パラメータを保管
const url = 'https://api.syosetu.com/novelapi/api/';
const weeklyURL = '?genre=201&order=weeklypoint&of=t-n-w-s-k-gf-gl-l-nu';
const monthlyURL = '?genre=201&order=monthlypoint&of=t-n-w-s-k-gf-gl-l-nu';

const axios = axiosBase.create({
baseURL: url,
headers: {
'Content-Type': 'application/json',
'X-Requested-With': 'XMLHttpRequest',
"User-Agent": "Mozilla/5.0",
},
responseType: 'json'
});

let outputText = null

const fileOutput = (text) => {

// weekly取得時は出力せずreturn
if(outputText === null) {
fs.writeFileSync("output.txt", '')
outputText = text;
return}

outputText = (outputText + text)
const arrText = outputText.split('\\n')
console.log(arrText)

try {
for(let txt of arrText) {
fs.appendFile("output.txt",txt+"\r\n",()=>{})
}

console.log("write end")
} catch (e) {
console.log(e)
}
}

const narouListGet = (adress) =>
axios.get("/" + adress).then((data) => fileOutput(JSON.stringify(data.data)))

narouListGet(weeklyURL)
narouListGet(monthlyURL)

楽さを重視したのでtext出力にしましたが、JSON加工だけできれば後フロントとの繋ぎだけなので
fsについては今回深く理解する必要はないかなと思ったため上書き更新による実装になっています。

実行結果

読んでみようかな、となる判断材料になる箇所だけ抜き出す形式にしたため、検索件数を増やすとか、
別ランキングを取得するところもパラメータ変更で対応できる形式となります。

止まったところ

api側使用について

userAgentが未設定の場合エラーページのhtmlがJSON返還されるため、
axiosのheaderに適当な値を追加してgetする形式としました。

fsモジュールappendFileの引数不足

fs.appendFile()は引数を3個取り、3個目がcallback形式でエラー出力に使用されるため
今回は特にエラーを考えない形で空関数を設定し回避しました。

まとめ

サイトopen→weekly一覧を撫でる→monthly一覧を撫でる、を1コマンドでできるようになったので
復習ついでとしては地味に時間短縮できるものができました。

・今回の実装だけの話
投稿系サイトにありえる「更新が止まっている物を読み始めても途中で止まり意味がない」問題を
今回はweekly/monthlyに上がってくる＝更新止まっていない、としてケアしていますが、
暇があったらnarou.rbと連携して読了済み小説のタグ抽出から好きな小説の傾向を判断して
自動取得するとかの拡張もいいかもしれないなと思いました。

参考

[axios]axios の導入と簡単な使い方
[node.js] テキストファイルを読みこみ

  • 2020.09.29

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機能が使えるかは別途確認すること)

  • 2020.09.27

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

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

各項目とも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は機能として使うため少し勉強する。

  • 2020.09.06

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を使用したいけどサクッと書けるので
選択肢として持っておきたい。