Markdown 既報の * + - による項目の違い

長年気になっていたけど、ようやく調べてみた。

結論からいうと、標準仕様では差異はないとのことだった。

daringfireball.net

It’s important to note that the actual numbers you use to mark the list have no effect on the HTML output Markdown produces.

リストをマークするために使用する実際の数値は、Markdown が生成する HTML 出力には影響しないことに注意してください。

なので、 * + - で動作が異なる場合は、全部方言っぽいということでよさそう。

実際どれを使うべき？ というのは個人的にも結構悩んでて、昔 (2016 年頃) のドキュメントだと

* ネストなしの勘定書きを並べる際は * で統一
* ネストなしの勘定書きを並べる際は * で統一
* ネストなしの勘定書きを並べる際は * で統一

+ 箇条書きでネストするときは、上位項目を +
  + 下位に項目が存在する限り、ネストしても +
    - ネスト最下部は -
    - ネスト最下部は -
  + 下位に項目が存在する限り、ネストしても +
    - ネスト最下部は -

みたいなことやってた。 ファイルシステムの階層を CLI で表現するときのアレに習ったんですかねえ。

なんかおかしい？

　

ちなみにはてなブログで上記のように書くと、ネストに対して区切りがなんかおかしい？ いやどうなんだろう正しいのかなコレ、よくわからん。

今はネストがあろうとなかろうと、全部 * で統一しています。 Bold (**) あたりと混同するからよくない、みたいな意見もこれあるので「なるほどなー深いな」となった。

Unable to monitor directories for changes because iNotify max watches exceeded.

• ロケ地： Amazon Linux release 2 (Karoo)

RAILS_ROOT で rails c したらエラーがでるー、と言われたやつ。 実際のエラーはこう。

/RAILS_ROOT/vendor/bundle/ruby/3.1.0/gems/listen-3.7.1/lib/listen/adapter/linux.rb:32:in `rescue in _configure': Unable to monitor directories for changes because iNotify max watches exceeded. See https://github.com/guard/listen/blob/master/README.md#increasing-the-amount-of-inotify-watchers .
 (Listen::Error::INotifyMaxWatchesExceeded)

全部以下に書いてある。

github.com

今回は AmazonLinux2 環境で RHEL の系譜なので以下を実行する。

[user@localhost ~]$ sudo sh -c "echo fs.inotify.max_user_watches=524288 >> /etc/sysctl.conf"
[user@localhost ~]$ sudo sysctl -p

inotify ってファイル監視の通知とかじゃなかったっけ……、と思ってたけど合ってた。

qiita.com

これ、たしかディレクトリを再帰的に監視しない、とかいうアレだった気がする。 ので、コンソール起動タイミングで RAILS_ROOT 以下どこかのディレクトリで、 inotify の監視数を超えるイベントが起こっているのだと思う。

Listen uses inotify by default on Linux to monitor directories for changes. It's not uncommon to encounter a system limit on the number of files you can monitor. For example, Ubuntu Lucid's (64bit) inotify limit is set to 8192.

Listen は、デフォルトで Linux の inotify を使用してディレクトリの変更を監視します。監視できるファイル数のシステム制限に遭遇することは珍しくありません。たとえば、Ubuntu Lucid (64 ビット) の inotify 制限は 8192 に設定されています。

https://github.com/guard/listen/blob/master/README.md#the-technical-details

ファイルシステム周りの問題、忘れた頃に出てくるのでなかなか思い出せないんだけど、シュッと対応できたのでよかったね。

assets が見えないのは net::ERR_HTTP2_PROTOCOL_ERROR かと思っていた

アカウント ID が異なる環境で、動いているアプリケーションを環境ごとクローンする、というタスクがあって、規模的に手動で作業しなおしても大丈夫だなと思って着手したらひどい目にあった、という話。

ページデザインが崩れる

デプロイして動作確認を行ったところ、 assets:precompile で生成されるファイル系が参照できず、ページデザインが崩れていた。

RAILS_SERVE_STATIC_FILES=1 指定してあるし、なぁんでぇ？ と Chrome の Console 開いたところ、以下のエラーが出ていた。

net::ERR_HTTP2_PROTOCOL_ERROR

「HTTP2 通信が出来てない？」 と思って調べたところ、Nginx のバッファ領域が無いんじゃないか？ 疑惑が。

qiita.com

Nginx の公式リポジトリからインストールしてるし大丈夫だろ！ と思いつつ調べたところ、ディレクトリが存在しなかったのでシュッと作成した。

sudo mkdir -p /var/lib/nginx
sudo chown -R nginx:nginx /var/lib/nginx
sudo systemctl restart nginx
sudo systemctl restart puma

これで解決やろガハハ！ と思ったらダメだった、なぜ。

二重圧縮の可能性

同じエラーメッセージでググッってたところ、 StackOverflow で「二重圧縮になってないか？」という記述を見つけた。

stackoverflow.com

ということで、 Nginx の Server 句内で gzip を off にしてみた。

gzip off;

ダメ、まあ期待はしてなかったよ。 別アカウント ID では動いてるコンフィグだしね。

まず HTTP2 に対応してる？

ここでちょっと悩んだけど、まずこのアプリケーション HTTP2 を明示的に考慮してないよな、となり「HTTP2 無効化してみるかー」に行き着いた。

まず HTTP2 有効化してるのどこだよ？ と思ったけど、冷静に考えて ALB だよね。

ALB の設定変更したところ

これで解決、 console から net::ERR_HTTP2_PROTOCOL_ERROR エラーも消えた。 いやーまさかこんな事だったとは。

HTTP3 に追いつけるのはいつのことになるやら、という気持ちになってしまった。

MySQL8 時代の GRANT

GRANT ALL PRIVILEGES ON example_database.* TO example_user@localhost IDENTIFIED BY 'password'; 
FLUSH PRIVILEGES;

長らくこの MySQL 5.x 世代の「ユーザ作成と同時に権限も設定する」というヤツになれすぎて、 MySQL8 世代のユーザ作ってから GRANT しろ、というやつが思い出せない。 おじいちゃんすぎる。

CREATE USER example_user@localhost IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON example_database.* TO example_user@localhost;
FLUSH PRIVILEGES;

ただのチラシの裏

近頃はやれマイクロサービスだ疎結合だ、HTTP ヘッダは最低限にしろ、などといって色々分解したがるけど、コードがデータベースに求める権限は ALL PRIVILEGES を期待して実装されている気がしてならない。 これは利用するフレームワークの ORM 仕様や、周辺エコシステムなんかの恩恵をカジュアルに受けようと思ったらそうならざるを得ないのはそうなんだけども。

SELECT, INSERT, UPDATE, DELETE あたりで絞ってしまうと、デプロイ時にこけがちで「そんなんじゃ甘いよ」みたいなことを実装と作業者両方から言われたりするパターンに遭遇する。 辛い。

RDS で MySQL 5.7.3x を動かしている環境で日本語入力ができない

タイトルのとおり。

RDS で MySQL 5.7.3x 系エンジンの環境で、年次更新みたいな処理でデータベースメンテナンスをしていたのだけど、 mysql コマンドで RDS に接続時 SELECT や UPDATE 発行時に日本語入力しても消える (コピペしても消える) 状態だった。

motomotosukiyaki.com

上記リンク先は Ubuntu だけど、 my.cnf から [client] [mysql] の記述を消したらなんとかなるっぽい。

のだけど、調べてる時間もなかったので

1. mysqldump で GTID など削除してローカルに持ってきて作業
2. RDS に戻す

という、邪悪な作業で回避した。

該当の環境、 mysql-community- 系の server 以外をインストールして運用している状態なので、おそらく /etc/my.cnf を修正すれば治りそうな気はする。

ERROR 3678 (HY000): Schema directory './example_development' already exists. This must be resolved manually (e.g. by moving the schema directory to another location).

タイトルの通り。

DROP DATABASE example_development; したらなんか残ってしまい、 rails db: 系コマンドも通らなくなった。

原因は、 mysql_data 以下のディレクトリにデータベース名のディレクトリが残ってしまっているので。

削除する

/usr/local/var/mysql/ は他環境の mysql_data の場合読み替えてくれ、という感じで。

cd /usr/local/var/mysql/
rm -rf ./example_development

権限がここだけ腐ってる、みたいなものでもなかったので、なんで削除できなかったのかは不明。

とにかくこれで CREATE DATABASE example_development; や rails db:create なども通るようになったのでセーフ。

bugs？

なんか登録されていたけど、バグではない……？ よくわからんな。

bugs.mysql.com

[WIP]Ventura とする

自分の環境構築用なので、もし dotfiles とか brewfile を流用する人はいらんものあると思うので注意してください。

作業メモ兼ねてるのであとで綺麗にします。