チュートリアルをモノにするために
Ruby on Railsのチュートリアルをまず1回はコピペで動作確認して「おぉ!!できてる」を感動できる。
でも、そこから脱皮しないことには自分のモノにならない。
私が進めたやり方をご紹介!
あと進めていく上で確認して困ったことの対処法。
Webアプリケーション
まぁエンジニア人生の大半は「オープン系」って分野なわけで。
最終型の想像はつく。
メモ用紙1枚に1画面イメージでアクションを書き出してみた。
これを元にまぁ仕様書をGoogleのスライドでまとめてみた。
普通はスライドで作んないんだけど、Railsはこんな視覚的なものがいいなって。
ここまでやって再度、チュートリアルで使えそうなもので組み立てていく。
でも、何が使えるのか・・・覚えているわけでもないから、なんか受験生的にポイントを全部書きだしてみた。
昔の人間なんで、手で覚えないと覚えられない。
書いても覚えられるわけじゃないけど、それでも「書く」って一度頭の中に記憶して書き写す行為なのでかなりいい。
リソースの考え方はWeb系だったら普通にある考え方だけど、書き出してすんなり入ってくる感じ。
チュートリアルを1回やってすぐに作ったのが「スクレイピング」だったから、リソースとかって考え方がまるでなかったから、ある意味あっちの方が大変だった。
そして、日々のススメ方を書きながら、仕事だったらどう進めるかってことを想定しながら行った。
まぁ納品とかって言う概念はないけど、ダラダラやっててもしょうがないから。それでも案外時間がかかった。運動不足過ぎて身体の調子が悪くなったからね。
それでも、チュートリアルに自分のやりたい要素を入れながらやっていて、戻したくなった。ごっそり要らないものを入れてたりして。
特にユーザー関連がかなりしっかりしたチュートリアルだけど、Herokuのデプロイでなかなかメール送信が出来なくて、それに時間を掛ける余裕がなかったので、ユーザー関連のメール送信をざっくり削除。
ってことは・・・かなり変更。
チュートリアルはTweet系なので多数のユーザーが勝手に登録してTweetするって形式なのでそれは必要ないと思ったんだよね。
あくまでも業務系で一般的なホームページにサービス情報とか会社概要をログインした人に限って登録・修正が出来るってことをしたかっただけだから。
ユーザーはあくまでも一人管理者を設定してその人が新規ユーザーを作るって言うのが一般的な企業の流れでしょ?ってことで、削除するってところ辺りでRailsでどうするかってことがわかってくるから、新規でプロジェクトを作成して、そこまでファイルのアップロードでやろうとしたのだけど、さすがに順序が・・・
テストで失敗するわけ。順序が違うと。
なので、もう一度トライ。
何度トライアンドエラーしたことか・・・
でも、仕事じゃないからいくらでもエラーをしておこうって感じ。
その分、いろんなことを調べた。
ブックマークが山になってきている。
入れたことも忘れてまた検索して同じページ見てたりするのだけど。
最初、エラーが怖かった。
チュートリアルではGREENって書いてあるのにREDだよ。
とか。
$ rails test
した表示が違うよとか。
どこで設定しているのかわからなくて困った。
書き出したつもりだったりするのだけど。
gitも最初はほんと手順を間違えたりしていつもいつもエラーで困っていた状態。
まずプロジェクト作るたびに「SSH鍵」をどうするのかわからなかった。
リポジトリ単位なのか?
全体なのか?
これが一番わかったかな。
あとはHerokuへのデプロイ。
チュートリアル段階でもトップページは表示されるんだけど、クリックした遷移先が表示されないがほんと多かった。
その場合は
$ heroku maintenance:on
$ git push heroku
$ heroku run rails db:migrate
$ heroku maintenance:off
とするといいって書いてあるのだけど。。。
あと、一番困ったのがCSSが反映されない!!!
チュートリアルだと最初に設定してその後だって変更しているのだけど、いちいち書かれていないからつい忘れる。
$ rails assets:precompile
これをまずいちばん最初にするらしいのだ。
難しいことは・・・慣れてきたらきっと理解できるので、っここは
$ rails assets:precompile
$ git add -A
$ git commit -m "Assets配下を修正した"
$ git push heroku master
ってことのよう。
gitとherokuもやっているとごちゃごちゃになってくる。
なんてことは普通あってはいけないのだけどね。
pushしてるのに反映してない!!!とかってなるとbranchも作らないでmasterで修正して・・・commitしてってことになるのだけど、普通これでいいのだけど、pushを忘れててやってしまってエラーとかrejectとか起きるわけで。
一番困るのが
! [rejected] master -> master (non-fast-forward)
こうなるとpushを受け付けないわけで。
$ git pull
で、fast-fowardをあわせてコンフリクトした部分を修正して改めてpushするってことが一番書かれているのだけど(会社だったら絶対この方法だな。)それをしても一向に変わらない。
コードの修正よりもファイルの追加とかだったりするとほんと変わらない。
これでうまく行ったらそれでいいのだけど、うまく行った試しはなかった。
次の方法
$ git fetch (リモートの変更を取ってきて)
$ git merge origin/master (マージする)
まぁ、これは先の方法と何ら変わりはない。
最終手段
$ git push origin master --force
もうね、これしかないね。
herokuも・・・
herokuでも同じようになった場合は
$ git push heroku master --force
で乗り切る。
こういうミスを重ねているうちに人間は学習をしてこういうことが起きなくなる(はず)
それを信じて修正する場合は一息ついて、状況を確認してから始める。それが一番大切。
最後に・・・
AWSに限らずローカルで作業をしている場合、忘れずにすること。
$ rails s
にしたまま終了しない。ctrl + c を忘れずにする。
そうしないとずーっとサーバー接続されたまま、そのうち、
$ rails s
で怒られる。
Address already in use - bind(2) for 127.0.0.1:3000 (Errno::EADDRINUSE)
これは「もうさ、既に使い切ってるんだよね。新しく接続するとこないし」ってことらしい。
えーーー!どうしたらいいの?最初出た時はパニックでした。
で、調べてみました。
対処方法としては
$ lsof -i :3000
ずらずら〜と出てきちゃいました。
なのでリストのPIDを切断していく作業です。
$ kill -QUIT
これで一安心。なんだけど、まだこれで安心してはいけない。
今度はAWSのインスタンスの「停止」をするべきだ。
Cloud9で作業しているだけなら別に「起動」したままにしておく意味はない。なので、毎回インスタンス画面で「停止」にしておく。
私、画面を閉じたら勝手に切断するのだと思っていたのだ。
だって、毎回ログイン聞かれるし。でも、それとこれは違うらしい。20日くらいにメールが来た。
「Your AWS account XXXXXXXX has exceeded 85% of the March AWS Free Tier usage limits, as shown in the table below. You can review this month’s usage at the AWS Billing & Cost Management Dashboard.」
とな。
えぇ〜!!そんな無料枠って何に対してなの?
Amazon EC2 Linux または RHEL または SLES t2.micro インスタンス使用(1 GiB メモリと、32 ビットと 64 ビットプラットフォームサポート)750 時間 – 毎月の連続実行に十分な時間
ということのようですな。
ってことで750時間ってどのくらい?
24時間✗31日なんですけど。
なのに、なぜか20日にもう85%使ってるって警告が。
計算が合わない。。。
まぁインスタンスが3個位使ってないけど、最初の頃、テストで作ったものが「開始」のままでした。。。これが一番問題。
ってことで課金がもう予測されてます。
う・・・先月なんて気にもしないで・・・500円弱くらい?
どこから引き落としになってるんだろう〜?
152円かな。今月は。
ってことで気をつけましょう。
はぁ〜これらに慣れていかなきゃ。