環境変数の置き方
環境変数の置き方
開発(ローカル)環境
環境変数入力画面にいく。
% vim ~/.zshrc
環境変数を入力する
iを押す。終わったらescを押して:wq
例)カードの場合
export PAYJP_SECRET_KEY='sk_test_************' export PAYJP_PUBLIC_KEY='pk_test_************'
入力内容を反映させる
source ~/.zshrc
ここまででローカルの環境変数は設定完了!
**カードの場合 jsに組み込ませる必要ある
% touch config/initializers/webpacker.rb
1 |
Webpacker::Compiler.env["PAYJP_PUBLIC_KEY"] = ENV["PAYJP_PUBLIC_KEY"]
|
1 2 3 |
const pay = () => {
Payjp.setPublicKey(process.env.PAYJP_PUBLIC_KEY);
|
**
本番環境
例)カードの場合
% heroku config:set PAYJP_SECRET_KEY='sk_test_*************'
% heroku config:set PAYJP_PUBLIC_KEY='pk_test_*************'
% git push heroku master
デプロイ(heroku)
Herokuにデプロイする手順
heroku create アプリケーション名
% git config --list | grep heroku
fatal: not in a git directory
以外が表示であればおk
% heroku addons:add cleardb
% heroku_cleardb=`heroku config:get CLEARDB_DATABASE_URL`
% heroku config:set DATABASE_URL=mysql2${heroku_cleardb:5}
% heroku config:set RAILS_MASTER_KEY=`cat config/master.key`
% heroku stack:set heroku-18 -a アプリケーション名
% git push heroku master
% heroku run rails db:migrate
その他
% heroku config
% heroku apps:info
% heroku logs --tail --app アプリケーション名
環境変数を置かずにgit push heroku masterした場合
環境変数を記述する
続いて
% git commit --allow-empty -m "空のcommit"
% git push heroku master
画像投稿 active storage導入
画像を投稿する
active storageを導入する手順
% brew install imagemagick
Gemfile
サポートモジュール(テストコードをまとめる)
サポートモジュール
テストコード内にて同じ記述を避けるために1つにまとめる。
supportファイルを作成し、その中にこのようなファイルを作る。
1 2 3 4 5 6 7 8 9 |
module SignInSupport
def sign_in(user)
visit new_user_session_path
fill_in 'Email', with: user.email
fill_in 'Password', with: user.password
find('input[name="commit"]').click
expect(current_path).to eq(root_path)
end
end
|
rails_helper.rb 23行目のコメントアウトを外す。
Dir[Rails.root.join('spec', 'support', '**', '*.rb')].sort.each { |f| require f }
同じくrails_helper内
Rspec.configure内に以下のように追加する。これはファイル名と一緒の名前。
RSpec.configure do |config| config.include SignInSupport
これでサポートモジュールを使えるようになる。
後はテストコード内で
# ログインする sign_in(@user)
のように使えばおk。
テストコード( ターミナルコマンド)
まずrspecを導入する。
Gemfile
% bundle install
|
% rails g rspec:install
rspec導入完了。
結合テストコードのsystem specはcapybaraで既にgemに入っている。
--format documentation
これを追加することでテストコードを可視化できる。
単体テストコード
% rails g rspec:model user
これでファイル作成
% bundle exec rspec spec/models/user_spec.rb
これでテストコード実行
**userのとこは任意で変えて。
結合テストコード
% rails g rspec:system users
ファイル作成
% bundle exec rspec spec/system/users_spec.rb
これでテストコード実行
**userのとこは任意で変えて。
検索機能
検索機能
ビュー
<%= form_with(url: search_tweets_path, local: true, method: :get, class: "search-form") do |form| %> <%= form.text_field :keyword, placeholder: "投稿を検索する", class: "search-input" %> <%= form.submit "検索", class: "search-btn" %> <% end %>
searchにはcollectionかmemberを用いる。
collection: idを指定しない
member: idを指定する
この差がある。idによって検索範囲を狭めたい場合はmemberって感じ。
ルーティングに書く
resources :tweets do resources :comments, only: :create collection do get 'search' end end
モデルに書く
def self.search(search) if search != "" Tweet.where('text LIKE(?)', "%#{search}%") else Tweet.all end end
*モデルに書く理由
ビジネスロジック(データとのやりとりに関するメソッド)はモデルに書く。
likeについて
where('title LIKE(?)', "%c%") | cが含まれるタイトル |
self.searchについて
このselfはTweetもことだと思われる。コントローラーでTweet.searchとなっているので。
コントローラーに書く
def search @tweets = Tweet.search(params[:keyword]) end
keywordをモデルの引数(search)に渡してる。
処理の手順
検索フォームに入力して検索する(リクエスト)→ルーティングでsearchアクションに→コントローラーでsearchアクションを行う。モデルにメソッドが書いてるので→モデルへ。処理をしてビューに返す(レスポンス)
部分テンプレート
部分テンプレート
複数のページにて、同じコードを書く場合、部分テンプレートを用いることによってコードを1つのページで済ます。
部分テンプレートのファイル
(例)_tweet.html.erbに記述する。
_を最初に持って来る。
使い方
部分テンプレートに書いた内容を持って来る
同一ディレクトリ内
<% @tweets.each do |tweet| %> <%= render partial: "tweet", locals: { tweet: tweet } %> <% end %>
partial:"tweet"というのが_tweet.html.erbを持ってきている記述。
別ディレクトリ内
<% @tweets.each do |tweet| %> <%= render partial: "tweets/tweet", locals: { tweet: tweet } %> <% end %>
partial: "tweets/tweet"
tweetsというファイル内にある、_tweet.html.erbを持ってきている記述。