現象は以下の記事と同じ、対処法もリンク先と同じです。 太古から anyenv 使ってる人以外は対応する必要ないやつですね。
削除した ndenv のパスから以下に変更して動きました。
macOS 環境なので、他 OS 環境の方は適時読み替えるかディレクトリ掘って確認してください。
export NODE_VERSIONS=/Users/${ユーザ名}/.anyenv/envs/nodenv/versions
このままだと移行できてるけど global に指定した node が存在しないので .node-versions が存在しないプロジェクトで node コマンドエラーが出る。
いや .node-versions 作っとけよ、という話なのですが歴史的経緯とかで作れない場合もあるので、 nodenv global で LTS のバージョンでも指定しておくこと。
なん……何？ (ここ数年 RDS ばかり使っていたので、生 MySQL を久しぶりに使った顔
GRANT ALL PRIVILEGES ${データベース名}.* ON ${ユーザ名}@localhost;mysqldump を実行したところ、表題のエラーが出た。 どうも PROCESS 権限が足りないらしいが、ダンプを取得したいデータベースに対して操作しているユーザは GRANT ALL している。 なん、なに？
Incompatible Change: Access to the INFORMATION_SCHEMA.FILES table now requires the PROCESS privilege.
This change affects users of the mysqldump command, which accesses tablespace information in the FILES table, and thus now requires the PROCESS privilege as well. Users who do not need to dump tablespace information can work around this requirement by invoking mysqldump with the --no-tablespaces option. (Bug #30350829)
訳すとこう！
互換性のない変更：INFORMATION_SCHEMA.FILESテーブルへのアクセスには、PROCESS特権が必要になりました。 この変更は、FILESテーブルの表領域情報にアクセスするmysqldumpコマンドのユーザーに影響するため、PROCESS特権も必要になります。表領域情報をダンプする必要がないユーザーは、--no-tablespacesオプションを指定してmysqldumpを呼び出すことにより、この要件を回避できます。 （バグ＃30350829）
CREATE LOGFILE GROUP と CREATE TABLESPACE 用の情報を mysqldump に含めないオプションらしく。
明示的に CREATE LOGFILE GROUP などしていないので、アプリケーションの規模も小さいし除外してしまっていいかな、という感じで、権限付与せずロングオプションを利用することで回避することにしました。
こんなかんじ。
mysqldump -u ${ユーザ} -p -h localhost --no-tablespaces ${データベース名} > ~/db_dump/`date "+%Y%m%d%H%M%S"`-${PREFIX}.sql
最近 git flow like なプロジェクトを見ることが多くて、feature ブランチが大量に発生しているので、日付と合わせてコミットされた時刻も出すようにした。
❯ git config --global alias.tree 'log --all --date-order --date=format:"%Y-%m-%d %H:%M:%S" --graph --format=" <%h> %ad [%an] %C(auto)%d%Creset %s"'
視認性は下がったけど、取得できる情報量は増えたのでこれで。
いつも git log -3 --graph とかしてるので、下記記事を参考に git tree を設定した。
git config --global alias.tree 'log --all --date-order --date=format:"%Y-%m-%d" --graph --format=" <%h> %ad [%an] %C(auto)%d%Creset %s"'
コメント兄貴の auto にしてみた。
わかりやすいのでワイは auto で行く所存。
画像のコミットログは、今一人で作業しているプロジェクトの直近の成果です……。
なんかこれも前に書いた気がするな。
#{RAILS_ROOT}/config/credentials.yml.enc は master.key が無いと復号化できなく欠けた状態では動きません。
master.key はたしか .gitignore に標準で記載されているので、何らかの手段で rails new した人が、チーム内で共有する必要があります。
#{RAILS_ROOT}/config/enviroments/ 以下の RAILS_ENV に対応する development|staging|production|test それぞれの .rb ファイルから以下のように記述しておきます。
# master.key を参照する (credentials.yml.enc を使う場合はこっち) # config.require_master_key = true # SECRET_KEY_BASE を参照する (credentials.yml.enc をやめる場合はこっち) config.require_master_key = false
マーこれ過去に「なくても動くでしょ」って言われて共有拒否られたのがトラウマになってて、 credentials.yml.enc 否定派になっちゃんすよね。
(動くって言ってた人が rails new してたので、そりゃあんたの環境では動くでしょうよ、という顔になっていた。)
正直なところ、昨今では .env .direnv 的なドットファイルで管理せず AWS のパラメタストアのような、インスタンスの外部に存在するサービスに秘匿保存しろ (インスタンスには依存する秘匿情報の類は保存しない、気軽に壊して作れるように) みたいな風潮を感じつつ。
Rails5.2 リリース当時の、ウェブアプリも暗号化がんばろうねとか Docker などコンテナが本格的になる前の風潮から進んだ感あるので。
コンフィグとして存在するのは確かにアリなんだけど、有効化はしなくていいよなって個人的な気持ちから無効化して運用しています。
以前も書いた気がするけど思い出せないので再度書く
anyenv update
よく忘れるやつ、最近の rbenv で --list-all オプションに変わったんだっけ？
rbenv install --list-all
rbenv versions
.ruby-version があると切り替わるやつ
rbenv version
ruby -v
