背景
ここ何週間かかけて演習支援アプリを作ってきました。学生がエラーを発生したきに、そのエラーを解決する支援をするシステムです。
これまで数年の論文ネタ（Railsプログラミング演習の分析と支援）がこの授業のこの回のデータを使ったものでした。本日３，４限がまさにそのタイミングだったのですが。。。
結果から言うと、途中までこのシステムが動作せず。。。データが半分くらい取れませんでした。
おいおい＞情けないなぁ。。。自分。
機能が少々複雑になっていたので動かすのは難しいな。。。と薄々思っていたので、予感が当たってしまった結果になります。自分の見積もりの甘さ。落ち込んでいます😅
昨晩も２時くらいまで通知が届かないなどあれこれやっていました。
詳しいことは省きますが、これまで数週間に渡って使ってみては思いつくたびにモデルを追加して操作記録など保存するようにしていたのですが、ログが分散するとあとで統合するのが非常に面倒になります。
そこで１つのEventlogクラスに統合しようというのを今日の０時くらいからやり始めたんですね。。。それはいいとして。
統合するということは既存のテーブルを削除することになるんですね。
開発テストはsqlite3だったのでマイグレーションスクリプトを書き換えて、sqlite3で直接テーブルをドロップしていました。開発モードしか利用していなかったのでそれでも不都合はありませんでした。あくまでプロトタイプなのでマイグレーションファイルを履歴で管理する意義を見いだせなかったからです。しかし、このアマチュア感覚が仇になりました。
何をしたか？（個人記録）
サーバはRender.comの無料プランを利用しています。DBサーバもRender.comで提供されているpostgresqlです。午前中も授業があり、昼ごはんを食べながら昨晩やり残していた動作確認がやっと終わりました。
午後の演習でとりあえず出だしの説明をして学生さんらが各自で課題を進めている間にデプロイ。すると。。。なぜかFailed。あれ？テーブルをドロップする操作はフラグを追加して実行しないとできないと。デプロイ用のスクリプトにフラグを追加して再度、デプロイ実行してみると、今度はDBにアクセスしているセッションがあるのでテーブルはドロップできないと。。。
DBサーバを外部からアクセスできないようにしたかったのですができず。
デプロイは失敗してもその前のバージョンの演習支援システムが動作しているため、学生さんがRailsアプリを実行するたびにDBに関係ファイルがアップロードされることに気づきました。
そこで、やったのが以下です。
ファイルアップロードを受け付けるルーティングを無効化した正常動作するRailsアプリをまずデプロイし、これで外部からDBサーバにアクセスするインスタンスはいなくなります。
ここでpostgresqlのDBサーバを再起動します。ここまでは無料インスタンスでもできます。
- 次にテーブルをドロップするコマンド（bundle exec rake db:migrate:reset DISABLE_DATABASE_ENVIRONMENT_CHECK=1）を追加しルーティングを正常なものに置き換えてデプロイ。これで無事、デプロイが成功しテーブルがすべて望みの状態になりました。
ここまでで演習開始後、40分くらい経過していました。最初の手順のエラー情報は失われてしまいましたね。。。その後はとりあえず動作したのである程度は情報が得られましたが。もう時間は戻せません。
ちゃんと被験者を用意した別の実験手順を考えましょう。。。それまでにはアプリは完成させないと。
以上、情けない結果でした。
