webアプリに挑戦してみたら躓きまくったので備忘録

webアプリに挑戦してみたら躓きまくったので備忘録

今回は久々にプログラミングネタです。これからプログラミングするぞ!とかwebアプリ作りたいって人の参考に成れば幸いです。私自身はド素人ド底辺なんちゃってプログラマーなので、話半分に読んでいただければ。

そもそもなぜwebアプリに挑戦しようと思ったか

僕は2017年6月から本格的にプログラミングを勉強し始めたのですが、その時はじめに作りたいと思ったのがwebアプリでした。ただ、webアプリはアプリを作ること以外にやるべきことが非常に多い。サーバーの管理・セキュリティ・ドメイン・・・。中でも初心者にはハードルが高いセキュリティ対策。ここをしくじると加害者になってしまうこともあるようだったので、いきなりwebアプリに取り掛かるのは断念し、まずはiPhoneアプリから作ってみることにしました。

そして、iPhoneアプリを7つほど作り(しょぼいやつを)ある程度自信ついたので、今回webアプリを作ってみることに!

今回作ったやつがこちらです!そんなに長い間公開し続けていないかもしれませんが。

https://upand.app/

構成

  • さくらVPS
  • ムームードメイン
  • ラピッドSSL
  • node.js
  • express
  • centos7
  • nginx
  • bulma

を使って作ってみました。中でも感激したのがCSSフレームワークのbulma!フレームワーク自体はよくある最近のイケてるフレームワークなのですが、それよりも公式のチュートリアル動画を見ているとなんと、動画中のテキストが選択できるんです!!!こんな感じ↓

https://scrimba.com/p/pV5eHk/c4EMaUR

これやばくないですか?

ドットインストールやyoutubeなんかで勉強することが多かった自分としては、喉から手が出るほど欲しかった神サービス。動画は残念ながらすべて英語ですが、プログラミング学習系の動画って、何言っているか理解できなくてもなんとなくわかるから不思議。

躓きその①マルチドメインの罠

さて、本題の躓きポイントですが、正直node.jsやexpressなんかは書き方は多少違うけど、プログラミング言語なのでそこまで困りませんでした。こういう時どう書くんだ?ってのはググればいい感じのお手本がいっぱい出てきますし。

問題は、ドメイン!!!!

ある程度完成が見てきて、公開用のドメインを決めようと!ただ、自分の勉強用アプリのためにドメイン新たに買うのももったいないなと思い、初のサブドメインなるものを使ってみることにしました。

サブドメインについて簡単に説明すると、このサイトのドメインがmasayuki031.comなのですが、app.masayuki031.comって前に単語をくっつけて親戚みたいなものを作るのがサブドメイン。

そしたら、新たにドメインを購入する必要もなく節約になる。

早速、masayuki031.comを購入したムームードメインでサブドメインの設定をし、nginx側でも設定。これでapp.masayuki031.comでwebアプリが公開できると思いきや・・・。

表示できず。centos7のファイアウォール側でブロックしてしまってるのか?と思いファイアウォールでの設定を見直すも、改善されず。

最終的にファイアウォールを無効にしても、改善されず。

centos7が問題でないならnginxか?ということで、nginx側での設定を見直すも改善できず。計6時間ほど格闘しましたが、改善できず。

諦めてトイレに行ってるときに気づきました。

もともとmasayuki031.comのドメイン自体は、ムームードメインで購入してるのですが、サーバー自体はさくらサーバーを利用しているためさくらサーバーにドメイン移管手続きを行っているのです。つまり、ムームードメイン側で、いくらサブドメインの設定を行っても、実際のアクセスを管理してるのはさくらサーバーなので、全く反映されず。(疲れ果てて深く検証していないので恐らくですが)

さくらサーバー自体は、サブドメインを別のサーバーにするってのが設定上出来なそうだったので、断念。

新たにドメインを購入することにしました。

躓きその②SSLの罠

購入するドメインを選んでいると、◯◯◯.appというドメインを発見!ちょうどwebアプリ専用のドメインにしたかったので、何も深く考えず。「.app」ドメインを購入したところ、なんと

「SSL」専用のドメイン!!!

このブログですらまだSSLに対応してないのに。

購入してしまったので、SSLの設定を行うのですが、SSLを発行する側からサーバーがほんとに所有物か確認されます。今回さくらサーバーのラピッドSSLを購入したので、さくらサーバーさんから「あなたのサーバーの◯◯/△△に□□.txtっていうファイル置いといてねー。それ確認出来たら、証明証発行するよー」ってメールが届きます。

メールの通りに、サーバー内の言われた場所にテキストファイルを設置するのですが、一向に証明書発行できず。試しに自分で外部からアクセスできるか確認すると、これまた出来ない。今回も

  1. centosの設定
  2. ファイアウォールの設定
  3. nginxの設定

と順に調べていくも改善できず。 よく考えたら、node.jsでget/postなどの処理をすべてさばいているので、node.jsで◯◯/△△の□□.txtへのアクセスを許可しないと駄目でした。

これで、無事証明証は発行してもらえました。

躓きその③JavaScriptの罠

ドメインの問題もなんとかできあとは、楽勝!と思いきや。今度はJavaScriptの同期処理という罠にまんまとハマりました。

JavaScriptは元々同期処理を行うのがすごく苦手らしく、そのまま処理を書くとコールバック地獄というものになるらしいです。

はい、なりました。コールバック地獄。

そこで、JavaScriptの今どきの同期処理をググったのですが、非常に分かりづらく。Qittaさんのこの記事をとりあえず処理の部分だけ変えて、試していくとなんとかなりました。Qitta様いつもありがとうございます。

https://qiita.com/rawHam/items/838eefc80bc35a90e49a

反省点

今回webアプリを作って次回への反省

  1. ハマったら、時間を区切って作業するべきだった
  2. 言語選択の時に、特にこだわりがない場合は情報が多そうなものを選択するべきだった

①はiPhoneアプリ作ってる時から気づいてたのですが、プログラミングで躓いた時って、意外と何か別のことしてる時、例えば散歩とか買い物してる時に、ふと「あ、そういえばこういうこと試してないぞ!」ってなって解決する場合が多い。ただ、作業中はもうちょっとで解決できそうと思いいずいたら3時間経っていたってことが多い。一見なんでもなさそうな躓きの方が時間を浪費してしまうことが多いので、次回以降は25分(作業)5分(休憩)を厳守して、このサイクルを3セット試して駄目だったら他の部分の作業って感じで割り切ろうと思います!

②は、本屋に行って愕然としました。

iPhoneアプリ勉強した時は、ドットインストールでざっくりと大枠を把握して、本で体系的な理解を深めるってパターンでうまく行ったので、今回も踏襲しようとしたら、そもそもnode.jsのまともな本がなかった。

なので、ググってググってで作業を進めていったのですが、swiftなんかの時に比べるとどうしても情報の量が少ない。

アレクサスキルがnode.jsで開発できるので、node.jsを今回も選択したのですが、まだまだショボ腕の自分には情報量が多そうなRailsとかを選択しておいたほうが良かったかなと。

という感じの日記ブログでした。今日も最後まで読んでくださってありがとうございます。ほいじゃーまたー