以前ブログに書きましたが、今回初めてオリジナルのWEBアプリを開発しました。ふとした思いつきで作り始めたチャートアプリですが、時間はかかりましたが自分としてはかなり多くのことを学ぶことができたので、反省と次回に生かしていくためにここでまとめようと思います。
今回は、アプリの概要と作成スケジュール、構築環境についてまとめております。他の記事でプログラミング関係についてまとめています。下記がプログラミング編の記事一覧になります。
独学でプログラミングを勉強していると、WEBアプリの作成の仕方や進め方は調べてもなかなかよくわからないことが多かったですが、ここでできる限りリアルな流れに沿って書くことで、どなたかのお役に立てれば幸いです。
ただ、今回については様々な制約があり、最終的には正式なデプロイにまでは至っていません。また熟練のプログラマーからすればおかしく感じる記載部分もあるかと思うので、その点は割り引いて見て頂ければと思います。
1. 作成したチャートアプリについて
まず、今回作成したアプリケーションについてですが、作成したのはチャートアプリになります。具体的にはbitflyerAPIからBitcoin価格情報を入手しチャート表示するもので、複数期間の表示が可能でかつ一定間隔で最新の価格に更新されるという機能を有しています。
bitflyerのサイトに載っているチャートを見ればいいじゃないかと言われれば全くその通りですが、当初は複数取引所の価格を一つのチャート上で表示することを考えていました。今回は正式なデプロイはしていないのですが、ローカル環境で動かしたアプリの利用動画は以下になります。
今回は、デザインや構成についてほぼ力をかけておらず、サーバサイドの開発に重きを置いています。期間表示とリアルタイムの更新、という部分で特に色々考えて作りました。
2. 作成スケジュール
まずは、作成スケジュールについての総括です。作成経緯と最終着地地点に至った理由についても記載しています。
2-1. 作成した経緯と結果
作成を開始したのは2018年6月になります。作成を開始した経緯は以下になります。
- 当時はまだzaifが元気な時期でデマや運営のミス含め、おかしな価格表示が話題になることがあった
- 仮想通貨への注目も依然残っており、取引所間のアービトラージ取引システム作成の需要がフリーランスサイトでも見られた
- 上記2点から複数取引所の価格データが(Coinmarket Capのように)統合されずに、1つのチャート上で表示されれば面白いのではないか、一定の需要があるのではないかと考えた
上記の様な考えとイメージで始めたチャートアプリの開発ですが、最終的にはチャートはbitflyerのみ、正式デプロイもしないことにしました。その理由は以下になります。
- 仮想通貨の価格下落が止まらず、かなり影を潜め始めていき、このWEBアプリへのニーズが感じられなくなった
- ただすぐにアプリ開発を中断するより、ある程度の形までいった上で次のアプリ開発に進んだ方が、次回への実りは多いと考えた
- プログラミングを学び始めた頃に借りて、ブログ用として未だに利用しているレンタルサーバが、予想以上に制約が多くデプロイどころかデータベースサーバとしての利用も厳しかった
- 総じて新たなコストをかけてまで正式デプロイする程のものとは感じられないが、ある程度の形までは持って行こうと考えた
上記が今回のアプリの開発経緯と今回の様な着地となった理由です。
2-2. 作成スケジュール
上記の様な経緯で始めたアプリ開発ですが、始めた後はかなり日和見的な進め方をしました。学習内容を中心としていますが、下記が作成スケジュールです。
- 2018.06
- APIからデータを取得する方法(データ取得の根幹となる部分)
- 定期的にプログラムが実行されるコードの書き方(APIから定期的にデータを取得するために必要な知識と考えたため。結果的にwhileループの活用とcronの存在を知り実装せず)
- 文字列型と辞書型を相互に変換する方法(jsonデータの処理のため。jsonモジュールの利用で不要に)
- 2018.07
- 文字列型の時刻の解析とタイムゾーンの取り扱い方法(bitflyerAPIの時刻データが文字列型のUTCベースで時刻の変換が必要だったため)
- jsonファイルの取り扱い方法
- pandasモジュール(チャートの元となるデータの処理に必須と思い勉強。その後マストではないと判明し(使った方がかなり便利ではある)結果実装せず)
- APIからデータを取得しCSVファイルに保存するクラス完成(csvにしているのはデータ保存にどのシステムを使うか考えていなかったため。結果的にMySQLを利用することにし書き直し)
- csvファイルからデータを取得しpandasでグラフを生成するコード作成(一旦グラフを作ってみようと考えて。WEB上でチャートを表示する方法についてはまだ何も考えておらず)
- デコレータ・高階関数について学習(コード作成過程で苦労したため。具体的にどんな場面かは記憶無し)
- 2018.08
- チャート表示に適したpythonのWEBアプリケーションフレームワークDashを学習(ここで具体的なチャートアプリの作成方法を学習)
- plotly.pyを学習(Dashのベースとなっているため)
- pandasのunixスタンプの処理方法を学習(UNIXタイムスタンプで保存することでDBの軽量化と様々な時間帯への対応の簡便さを持ち合わすため。pandasにしたのは勉強したばっかりだったため)
- 開発環境について調査(MySQLなどのソフトのインストールでローカル環境を汚したく、一方で本番環境を見据えた構築が必要と感じたため)
- 2018.09
- 引き続き開発環境について調査(VM使うかDocker使うか決めあぐねる)
- Dockerの学習(Dockerの方が環境構築が簡単、最近主流になりつつあるとの評を見て開発環境にDockerの利用を決定)
- 2018.10
- 引き続きDockerを学習(最新 is BEST、シェアNo.1 is BESTという偏見からベースOSはubuntu(Linuxでの世界シェアNo.1)、アプリversionは最新(標準リポジトリになければソースからゲット)にこだわる -> vimをソースから導入しようとしてつまづく(標準リポジトリが最新のものだったとのち判明))
- Docker上でMySQL環境を構築し、MySQLを学習(ここでようやくデータ保存の方法を決定)
- 2018.11
- pythonのmysqlドライバ,mysql-connector-pythonの利用方法について学習(公式のためこのドライバに決定)
- UNIXタイムスタンプの処理方法について再度学習(pandasは高機能な分、負荷が高いという思いつきからシンプルな方法を再度調査・学習)
- slackAPIの利用方法(エラー発生時にslackに連絡が行くようにするため。実際に実装)
- configparserモジュールの学習(APIからデータ取得するプログラムの設定情報の取り扱いのため。未だにベストプラクティスは分からず)
- エックサーバでのMySQLの操作方法(エックスサーバへのデプロイを念頭においていたため。種々の理由から最終的に断念)
- Dashについて復習(開発環境あたりで大幅に脱線し利用方法を忘れたため。この時にやっとリアルタイムでチャートを更新する具体的な方法がわかる)
- 2018.12
- エックスサーバでDashアプリをデプロイする方法(シンプルなアプリは可能だが、リアルタイムチャートはCGI利用では負荷が高すぎて無理だと判明した -> 結果的にApache,nginxのWEBサーバ学習の泥沼に)
- Apache、nginxのWEBサーバの学習(dockerを利用したせいかcgi+appサーバ、fastcgiの利用でつまづくが解決に執着し泥沼 -> 結果解決せず、エックスサーバでfastcgiやuwsgi使えずwebサーバ+appサーバとしての利用断念)
- unixタイムスタンプから時刻オブジェクトに変換する方法(チャート表示を見据えて)
- mysql-connector-pythonのexecute,fetchメソッドを学習(重要だがよくわかりにくかったため)
- エックスサーバのMySQLにSSHトンネリングで接続する方法を模索(接続できず断念->エックスサーバの利用を全面的に断念。集客が見込めるようなアプリでもないためローカルサーバでの実験で終えることを決断)
- pycharmにコード実装・デバッグ
2-3. 総括
上記の様な非常に日和見的な開発の流れになりますが、その総括は以下になります。
- (反省点)
- 日和見的かつ無計画な進め方をし、非常に非効率な開発であった
- 重要でない部分でも、分からないことをスタックオーバーフローなどで質問せずにひたすら調べ続けたり検証を続けるなど、時間を浪費することが多かった
- レンタルサーバでもある程度できるという誤解をし、その制約について理解できていなかった
- (良かった点)
- 初めてのWEBアプリ制作で事なかれ主義的に進めたことで逆にその都度の疑問に合わせ幅広く学ぶことができた(python以外にdocker、PUSH通知、apache、nginx、ubuntu、centOS、unix timestamp、mysqlなど)。
- 学習する際にその分野の基本から体系的に、かつ疑問を埋めるようにして学習を進めたため、各分野の理解が進んだ
- ブログを書いたことで時系列での進捗と学習内容が記録できており、振り返りしやすかった
- 英語でも怯まずに公式ドキュメントを積極的に参照したこと
- 図示することで理解が進み、また振り返り時に学習内容の想起が容易になった
- (次回への指針)
- 構成や流れ、技術について全体概要を構築し、ある程度イメージを具体化した上で作業を開始する
- 30分から1時間調べて分からないことはすぐに質問サイトなどで質問する。質問しても要領を得ない場合は見切りをつけ、違う方法を考える
- レンタルサーバを頼りにしない
- キリの良い単位でブログを書く
- ややこしい概念や構造を持つものほど、しっかり図示し整理する
ブログについては、昨今アプトプットの上で勧める意見をよく聞きます。しかし、私個人としては、知識の定着の上ではブログを書くことはそこまで大きな効果がある様には感じておらず、むしろ体系的に学び、それをしっかりノートに記録するという方が重要に感じます。
ただ、文章力の向上や振り返りのための記録、集合知への貢献など、それ以外での意味合いは非常に大きいと考えています。勝手ながら、私の学習スタイルを紹介したいと思います。
- Pythonのパッケージやモジュール(pandasやplotlyなど) -> 公式ドキュメントのチュートリアルをベースに学習、jupyter labで専用ノート作成
- PythonのWEBアプリケーションフレームワーク(Dashなど) -> 公式ドキュメントのチュートリアルをベースに学習、jupyter labで専用ノート作成。コードの実験はPycharmで専用プロジェクト作成
- Pythonの特定用途のプログラム(自作関数やアルゴリズム的なもの) -> アルゴリズム集という名のjupyter labの専用ノートに記録
- Python以外のソフトウェアやプロトコルなど(dockerやHTTPなど) -> 専用のテキストファイル(リッチファイル形式)を作成し、基礎から記録。わかりにくい部分は構造を図示し可視化
3. 構築環境
次はWEBアプリの構築環境全般についてです。基礎となる環境は以下になります。
- PC: Macbook air
3-1. 開発環境
開発環境は以下の様な環境になります。
もはや開発環境と呼べる代物でないですが、初のWEBアプリ開発ではメインのpythonをPC上に構築してしまっても特段問題はないのかなと思います。
MySQLについては、他のデータ保存方法がある中での一つの選択肢であるため、docker上に構築することでPCの環境が汚れない様にしました。
3-1. 総括
開発環境の総括は以下になります。
- (反省点)
- WEBサーバを想定していないなど総じて本番環境を見据えていない
- gitを使っていない->進捗やバージョン管理ができていない
- (良かった点)
- python実行環境をlocalにしていたためある程度のパワーを確保できていた
- MySQLはDocker上に構築したことでMacの環境を汚さずに済んだ
- (次回への指針)
- 関数やメソッドの作成、細かいプログラミングの確認はjupyter labで行い、ある程度まとまればすぐにpycharmにコピー・デバッグという流れの方が開発効率が良さそう
- 本番環境を見据えた上で開発環境を構築する(VPS、PaaS、IaaSなど)
- gitでバージョン管理を徹底する
3-2. 本番環境
本番環境とはもはや言い切れないですが、最終的な構築環境は以下になります。
本来イメージしていた本番環境は以下になります。
3-2. 総括
本番環境の総括は以下になります。
- (反省点)
- 種々の制約や考えのもと、正式にデプロイしなかった
- それゆえ本番環境で正式に動くかは未だ不明
- 制約の多いレンタルサーバに頼ろうとしすぎた
- (良かった点)
- 疑似本番環境が自身のPCであるため、今回はセキュリティをそこまで気にしなくて良かった
- (次回への指針)
- 正式なローンチまで持っていく
4. まとめ
以上が作成スケジュールと構築環境についての総括です。正式にデプロイしていないので、まだまだ対応しなければならないことが隠れているだろうというのが本音ですが、一旦は形にできたのは良かったと思います。