AR ホームベーカリー

オイラのアウトプット用ホームベーカリー!

勉強系リンク

ブラウザの非アクティブなタブにしておくのもアレなので、気付いたらちょいちょいとメンテしていきたい

時事とか技術的な

https://speakerdeck.com/tumada/jie-xiang-du-wogao-meru

https://speakerdeck.com/tumada/sutatoatupunoaideaxuan-ding-gaido

https://speakerdeck.com/pfn/llmnoxian-zai

https://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433/265459/1/Version2021_10_08_01.pdf

https://ocw.tsukuba.ac.jp/course/systeminformation/database-systems-i/

https://tomomano.gitlab.io/intro-aws/#_%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB

コンピュータサイエンス

https://speakerdeck.com/e869120/150-fen-dexue-bugao-xiao-shu-xue-noji-chu

https://cs50.jp

rails console で利用できるモデルの表示

console から .find_by(id: 1) とかして見えないモデルがあってうーん?と思っていたんだけど、単純にモデルがないだけだった。

以下のようにすることで、扱えるモデル一覧が出力できる。

tables = ActiveRecord::Base.connection.tables
tables.map(&:classify).map(&:safe_constantize).compact

acoder.hatenablog.com

普段使ってないとマジで忘れるなこのあたり。

マイナンバーカード

www.watch.impress.co.jp

へぇーっ、通知書届いたらカードと一緒に持っていくだけでいいのか。

個人的には IC 埋め込まれたカード類はスマヒョなどに紐づけではなく一括で組み込んでしまうの、機種変更の時の移行がうまくいかない経験しかないので、このようなカードは単独で持っておきたい派なので参考になった。

いやスマヒョデバイスとかに入れちゃうの、便利ではあるんだけどね。 製品寿命もそうだし、突然死した時にデータ取り出せないから物理層でわけておくのがまあ信頼度的には高いよね、と iPhoneX が突然死した事を未だに恨んでいてそう思っているのだった。

なお iPhoneX からサルベージできなかったのはパズドラのデータです……(小声)。

マイナ保険証

これとは別だけど、マイナンバーカードに保険証が合体するのでいまのうちに申請しておくか〜、と毎年確定申告するたびに思っているので、やることにする。

AppleSillicon で古い Ruby を build する その3

せっかくなので、Rails 5.1 の古いプロジェクトで実際に Ruby 2.5 を動かせるか試してみた。

僕の場合の対応なので、個々のプロジェクトでは異なると思いますが、こんな古いバージョン使う以上自己責任だよ自己責任! という気持ちで参考情報として見てください。

これまでの流れ

donbulinux.hatenablog.jp

donbulinux.hatenablog.jp

対応が必要だったトコ

  • curb 0.9.4 を使っていてビルド失敗したので対応した
    • 0.9.11 にバージョンアップした
  • mysql2 がビルド失敗したので対応した
    • zstd のパスを雑に通した
    • ssl のパスを雑に通した

以下に詳細を書いておく。

curb 0.9.4 だったので 0.9.11 に bundle update curb した

元々 zipline 1.0.1 を使っていて、依存性の解決で以下のようになっていた。

    zipline (1.0.1)
      curb (>= 0.8.0, < 0.10)

zipline の対象バージョンからリリース時期や依存性解決に必要そうなトコから 2018 年あたりのものを選択して 0.9.x の最終版を選択したところシュッと解決できたのでオッケー。

Gemfile のバージョンアップ方法

https://qiita.com/morioka1206/items/19410fe414f441583998#gem%E3%81%AE%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E6%8C%87%E5%AE%9A%E6%96%B9%E6%B3%95

バージョン指定の記号をよく忘れるんだよなあ。

mysql2

ld: library 'zstd' not found

zstd のパスがなかったので、雑に通した https://zenn.dev/yukionodera/articles/how-to-fix-error-mysql2

export LIBRARY_PATH=$LIBRARY_PATH:$(brew --prefix zstd)/lib/

ld: library 'ssl' not found

mysql2 が参照したい OpenSSL のパスが通ってない? っぽいので、これ Ruby が依存する v1 系なのか MySQL が依存する v3 系なのか? とりあえずえいやって雑に通した。 https://qiita.com/ffggss/items/2a6e965c8c3133a92eb9#%E8%A3%9C%E8%B6%B3

❯ brew --prefix openssl
/opt/homebrew/opt/openssl@3
❯ bundle config --global build.mysql2 --with-opt-dir="$(brew --prefix openssl)"

動いたので大丈夫そう。

mysql2 公式の Readme

上記のどっちのパス問題だけど、Readme には以下のように書いてある

https://github.com/brianmario/mysql2?tab=readme-ov-file#mac-os-x

openssl@1.1 を使ったほうがよさそうだけど、

Later versions of MacOS no longer distribute a linkable OpenSSL library. It is common to use Homebrew or MacPorts to install OpenSSL. Make sure that both the Ruby runtime and MySQL client libraries are compiled with the same OpenSSL family, 1.0 or 1.1 or 3.0, since only one can be loaded at runtime.

MacOS の新しいバージョンでは、リンク可能な OpenSSL ライブラリは配布されなくなりました。 OpenSSL をインストールするには、Homebrew または MacPorts を使用するのが一般的です。実行時にロードできるのは 1 つだけであるため、Ruby ランタイムと MySQL クライアント ライブラリの両方が同じ OpenSSL ファミリ (1.0、1.1、または 3.0) でコンパイルされていることを確認してください。

とのことで、 RubyMySQL は同じ OpenSSL をリンクしてる前提の書き方なので、今回は Ruby 2.5 と MySQL 8.2 で動かすので当てはまらないので、動けば正義の理論でいく。

はい

はいじゃないが。

とはいえアレなので、追試として使っていた mysql2 0.5.3 を執筆時点で最新版の 0.5.6 にしてみた。

cat Gemfile

# 一応考慮はされていた
# gem 'mysql2', '>= 0.3.18', '~> 0.5'
# ちなみに Rails は Gemfile.lock を見たら rails (5.1.7) だったので普通にアレだけどまあ動く対象バージョンだった

❯ bundle update mysql2

... snip ...

Fetching mysql2 0.5.6 (was 0.5.3)
Installing mysql2 0.5.6 (was 0.5.3) with native extensions

... snip ...

Bundle updated!

一通り終わったので

動作確認を兼ねて最初から通します。

rm -rf vendor/bundle
❯ bundle install --path vendor/bundle

... snip ...

Bundle complete! 73 Gemfile dependencies, 191 gems now installed.

ということで無事最後まで bundle install が実行でき、中途半端にバージョンアップなどしていた環境が無事動きました。 やったあちょっと保守が楽になるぞ。

いつまでも古いバージョン使ってんじゃねえ

それは仰るとおりなのですが、往々にして予算の都合とか「エンドユーザに見えない部分より見える部分を優先しろ!」と滅茶苦茶怒られて、使っているライブラリ (UI や機能に影響するトコ) の差し替えで大規模に工数変わったり、機能や使い勝手が変更される、みたいなのが発生するので実施できていないんですよね。

という環境でした。

初期構築していた人が全員いなくなって、残ったのは spec が必ず落ちる (ダミーの初期データ投入タスクすらない) バージョンアップができない環境、となりめちゃくちゃ辛いのだけど、結局誰もやらないので巻き取るかあ〜、となったりしていたので最初の一歩としてマトモに動く環境を構築しなおせたのは良かった。

という訳で最後はちょっと愚痴っぽくなりましたが、古いプロジェクトの敗戦処理とかまきなおしをする (している) 人、がんばりましょう! 新年度なので一発景気づけという気持ちでした。

AppleSillicon で古い Ruby を build する その2

以前、古い Ruby を AppleSillicon な環境でどうするか、みたいなアレ第二弾。

第一弾の時は「ふーんやるじゃん!」みたいな気持ちだったのだけど、いざやってみるとちょっとコツが必要だった。

これまでの流れ

donbulinux.hatenablog.jp

素朴にやる

2.5 系が欲しかったので 2.5 を例にする。 (無理やり 2.5.x とか 2.6.x をインストールしていたけど、なんか動きが怪しかったので)

❯ git clone https://github.com/hsbt/old-ruby-build.git
❯ cd old-ruby-build
❯ ruby ./build.rb 2.5 ~/.rbenv/versions

... snip ...
(ワイの環境では homebrew の update と bison のインストールが走った)

==> Running `brew cleanup bison`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

これで 2.5.9 が追加されているはず。

❯ rbenv versions
* system
  2.5.1
  2.6.3
  2.6.5
  2.6.10
  2.7.6
  2.7.7
  3.1.0
  3.1.2
  3.1.4

無い。 ナンデ!?

ここで一旦ビルド先を見てみましょう。

❯ gls ~/.rbenv/versions
total 0
drwxr-xr-x 3 donbulinux staff  96  4  3 17:12 .
drwxr-xr-x 3 donbulinux staff  96  4  3 17:12 ..
drwxr-xr-x 6 donbulinux staff 192  4  3 17:12 2.5.9

ああ〜ん? 他バージョンもないやんけ、で気付いたんだけど、anyenv を利用しているのでこのパスだと認識しねえわ!

僕の環境では正しくは以下のパスに放り込む必要がある。

❯ gls ~/.anyenv/envs/rbenv/versions
total 0
drwxr-xr-x 11 donbulinux staff 352  6 27  2023 .
drwxr-xr-x 21 donbulinux staff 672  1 26 19:52 ..
drwxr-xr-x  7 donbulinux staff 224 12  9  2022 2.5.1
drwxr-xr-x  7 donbulinux staff 224  2 26  2023 2.6.10
drwxr-xr-x  7 donbulinux staff 224  2 26  2023 2.6.3
drwxr-xr-x  7 donbulinux staff 224  1  5  2023 2.6.5
drwxr-xr-x  7 donbulinux staff 224 12  9  2022 2.7.6
drwxr-xr-x  7 donbulinux staff 224  2 14  2023 2.7.7
drwxr-xr-x  7 donbulinux staff 224 12 23  2022 3.1.0
drwxr-xr-x  7 donbulinux staff 224  2  2  2023 3.1.2
drwxr-xr-x  7 donbulinux staff 224  6 27  2023 3.1.4

anyenv 環境下でやる

というわけでやり直す。 同じ様に ~/.rbenv/versions にビルドしちゃった人、そちらは削除しておいてください。

❯ ruby ./build.rb 2.5 ~/.anyenv/envs/rbenv/versions

==> Downloading https://formulae.brew.sh/api/formula.jws.json
###################################################################################################################################################### 100.0%
==> Downloading https://formulae.brew.sh/api/cask.jws.json

Warning: rbenv/tap/openssl@1.0 1.0.2u is already installed and up-to-date.
To reinstall 1.0.2u, run:
  brew reinstall openssl@1.0
Warning: openssl@1.1 1.1.1w is already installed and up-to-date.
To reinstall 1.1.1w, run:
  brew reinstall openssl@1.1
Uninstalling /opt/homebrew/Cellar/bison/3.8.2... (99 files, 3.7MB)
Unlinking /opt/homebrew/Cellar/openssl@3/3.2.0_1... 5802 symlinks removed.

... snip ...

==> Summary
🍺  /opt/homebrew/Cellar/bison/3.8.2: 99 files, 3.7MB
==> Running `brew cleanup bison`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

❯ rbenv versions
* system
  2.5.1
  2.5.9
  2.6.3
  2.6.5
  2.6.10
  2.7.6
  2.7.7
  3.1.0
  3.1.2
  3.1.4

❯ gem install bundler -v=1.17.1 --no-ri --no-rdoc
Fetching: bundler-1.17.1.gem (100%)
Successfully installed bundler-1.17.1
1 gem installed

無事 2.5.9 が生えましたね! bundler の 1.x 系も入ったのでこれにて平定。

注意点

ログをちょっと書いたけど、 OpenSSL の reinstall と unlink -> link が走っているので、これらに影響があるアプリケーションを使っている場合、ワンチャン壊れている可能性があります。 (MySQL とかね)

大丈夫だと思うけど各々の環境によるので、一応プロセス再起動なりなんなりして確認しておこう!

とはいえ古い環境が必要ならコンテナなり VM でやれよ、と言われたら時代の流れ的にはそうなんだけど、理解しているからこそちょいちょい辛くなりますね。

続きを書いた

この流れを踏まえて実際に古いプロジェクトで動かせるか試してみた。

donbulinux.hatenablog.jp

bundle 周りでちょっと詰まったけど、今のトコロ概ね動いているので感謝感謝である。

(一応バージョンアップブランチもあるんだけど、ビジネスロジック由来の spec が落ちまくっていて修正にめっちゃ手間取っていたりしているのだった)

XZ Utils の脆弱性のやつ

CVE の base score が満点 10 点なの久しぶりに見たなあ! という感じです。

piyolog.hatenadiary.jp

OSSサプライチェーン攻撃でここまで大規模かつ注入成功したの珍しい事例、なんですかね。

元々の XZ Utils 開発者兄貴が、おそらく共犯の人にめっちゃねっちょり言われて精神的に「めんどくせぇー!」となったのと、一部の話だとデジタルデトックス? かなんか知らないけどネットを断つタイミングがあるらしいということで、色々積み重なった結果だったのかなあ。

なお周囲では homebrew 経由で 5.6.x を入れている人もいなかったし、管理している環境下ではベータバージョンのディストリを採用している環境も存在していなかったのでセーフでした。

とはいえ毎月作っている月次報告書に、自主的に付記つけるくらいにはインパクトあったね。

RDS (db.t2. と db.t3.) の CPU クレジットの違い

どちらも Unlimited だと思ってたんだけど、実は違ったという話。

aws.amazon.com

まず、CPUクレジットの計算方法は、基本はAmazon EC2と同じです。db.t2.だとStandard Modeに相当する制限があり、CPUクレジットが0になるとベースライン以下のCPU使用率に制限されます。db.t3.ですと、Unlimited Modeに相当する動きとなり、CPUクレジットが0になると追加の課金が発生します。モードの説明は「T系インスタンス利用時の注意点」の項をご覧ください。

はーなるほど、 db.t2. と db.t3. では CPU クレジット枯渇後の動作違うのか! という学びあった。