DeleteとRemoveの使い分け
あんまり意識せずにメソッド名やコメントにdeleteをよく使ってたんだけど コミットコメントに関して調べてたら興味深い使い分けを知ったのでメモ。
Microsoftスタイルガイドの指標
- Delete ファイル自体を削除する時
- Remove ファイルの内容、項目等を削除する時
removeの訳は取り除く。削除というより移動させる。
deleteとすると完全に消すイメージになるので
removeを使うと削除ではないことがわかりやすいからだとか。
コマンドでファイル削除にrm(removeの略)を使ったりするからなんか違和感が^_^;
参考サイト
Git リモートリポジトリにあるブランチを取得する
GitHub プルリクエストマージ後の修正について
GitHubプルリク後の修正は、再度プルリクを作る
プルリク後に修正が出た
- ローカルのブランチ(プルリクしたブランチ)を修正
- 一度Pushしたローカルブランチを再度GitHubにPush
- マージ後のプルリクサイトには何も反映されない
プルリクサイト(マージ後
- マージしたプルリク、ブランチについては完了扱い
- とっとと該当のブランチ消してしまえ状態
- ブランチが同じでも、その後の更新はここには反映されない
同じブランチを更新してPushすると?
- ホーム画面(たいていmasterブランチ)に更新ありましたよと通知が表示される
- 通知に再度プルリクを作成しますかとリンクがある
- そこから新しいプルリクを作成して、再度マージ申請を行う
MiniTestのassertionについて
assert notではなく、refute
assert_not〜があると思って必死にさがしてたら
refuteでした。どうりで全然ヒットしないわけだ。
馴染みがないので調べたら
refute の英語訳は誤りを証明するでした。
探してたのはまさにコレ!!
2018.10.18 追記
assert_no_text とか見つかったわ。なんなんコレェw
PostgreSQLコマンド すぐ忘れるのでメモ
普段あまり使わないが、Heroku等の本番環境がPostgresqlだったりするのでよく使うコマンドのメモ。
起動
% pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start
ログイン前
- バージョン確認
% psql --version
- DBの一覧表示
% psql -l
- ログイン
$ psql DB名称
ログイン後
- テーブル一覧表示
# \d
- テーブル内容表示
# \d テーブル名称
- テーブルのアクセス権限表示
# \z テーブル名称
- ログアウト
# \q
Herokuデプロイ手順
前提条件
- Railsプロジェクトが対象(1のGem以外は共通だろうけど
- ソースをGit管理していること
1. Gemに以下を追加
group :production do gem 'pg' end
※これは本番環境だけに必要なものなので'production'でグルーピングしている
HerokuはDBがSQLiteをサポートしてないため
sqliteのGemはdevelopmentグループへ入れること。
2. 上記Gemインストール
ローカル環境にはインストールしない設定でGemfile.lockを更新するのが目的。
% bundle install --without production
3. PCにHeroku環境があるか確認。無ければHerokuCLIをインストール。
% heroku version
HerokuCLIのインストールは以下。Macであればhomebrewで簡単インストール
4. Heroku ログイン
% heroku login % heroku keys:add
Herokuユーザー登録がまだであれば以下で登録。 本人確認にクレジットカード番号が必要だったはず。基本無料だけどちょい不安なるよね
5. Herokuにアプリケーション作成
% heroku create
6. Herokuデプロイ
% git push heroku master
7. Heroku上のDB作成、更新(デフォルトDBはPostgreSQL)
% heroku run rails db:migrate
8. Heroku上で確認。以下コマンド打つとブラウザで開いてくれて便利
% heroku open
※動かない場合、heroku logsとコマンドで打つとログ見れますが
エラー原因不明の場合はとっとと作り直したほうが早いです。たまにあるそうです。
僕もなったことありますエラーコードH10。作り直したら動きました。
mintestでの遷移テスト
mintestでは status_codeを利用。でもキャッシュには注意!!
Railsでのテストコードに関して
これまではrspecを利用してテストしていた。
が、現在Railsに標準でつくのはminitestになっている。
できるだけ、標準を使うべきという指摘もあり。
また自分もそう思うのでminietstへ移行してみた。
minitestへの移行
まずはシステムテストを書こうと思ったんだけど
scaffoldで作成時に、自動で書いてくれるコードを見ても遷移テストがない。見落としてるかもだけど。
assert_responseだと思ったけど情報少なかったので残す。
rspecはあるんだけどね。
minitestでの遷移テスト
やりたいことrspecだと
visit root_url
expect(page).to have_http_status(:success)
minitestだと
visit root_url
assert_equal 200, status_code
:success とか用意されてると嬉しいよね。 200番台ならば成功と判断できるやつ。
これでうまくいくと思ったら304が返って来てうまく行かなかった。 原因調べたらどうもpoltergeistの仕様でキャッシュ使っちゃうようで 304ステータス:エラーじゃないけど更新されてないよ。キャッシュがあるよ〜。
ということで
page.driver.clear_memory_cache
を事前に書いておけばキャッシュがクリアされて期待する200コードが返ってきました\(^o^)/