■

cookiesのサイズ制限っていまどんな感じですか

発端はこのコミットを見たことAdd details of cookie name and size to CookieOverflow exception · andyw8/rails@0ec8f21
クッキーの値が4096バイトより大きければエラーになっている
- コミットは、エラー時にどの名前のクッキーがどの容量なのかをエラー文言に含めるぞ、というもの
1つのドメインが複数のクッキーを扱っているときに、全体として 4096バイト以内じゃないとだめなんじゃなかったっけ…？
- そしてそうだとすると単一のクッキーが4096バイト以内でエラーにならなくても、ブラウザ側で期待しない挙動(例: 値がtruncateされる)になったりするケースがあるだろうか？
- と思ったので調べた
いまのchrome(107.0.5304.110)だと1つのクッキーあたり4097バイトまで格納でき、かつドメインあたり180個のクッキーが設定できる
- ドメイン全体で4096バイト以内、みたいなのはIEなどの古いブラウザの話だった模様
↑のRailsの実装で問題ないぞ、というのを確認できた

参考

2022-05-12

default gemとrubygems.orgから取得するgemの違い

default gemとは、standard librariesとdefault gemsとbundled gemsの違い - esm アジャイル事業部開発者ブログが詳しい
default gemはrubyがビルドされるときに一緒にビルドされており、rubygems.orgで配布しているものと同じバージョンを指していてもコードは多少異なる可能性がある
例としてzlibライブラリをあげる
執筆時点の最新は2.1.1
- これは2021年の10月にリリースされている
  - zlib | RubyGems.org | コミュニティのGemホスティングサービス
- Ruby3.1は2021年の12月にリリースされている
  - これに入っているzlibのバージョンは2.1.1
gemでインストールしたzlib 2.1.1とdefault gemとしてインストールされているzlib 2.1.1は2021年10月~12月に入ったコミットぶん差がある
- 例えばZlib::InProgressErrorという定数が2021年11月に入っている
  - [Bug #18358] Fix crash in zlib when in progress · ruby/zlib@50fb8a0
- Ruby3.1で↓を実行するとエラーにならないが、Ruby3.0などでzlib 2.1.1を手動でいれて実行するとuninitialized constant Zlib::InProgressError (NameError)になる

require 'zlib'
Zlib::InProgressError

2022-03-14

Rails7でシステムテスト失敗時のスクショが保存されるディレクトリが変わる

Rails7未満でスクショが保存される先は"tmp/screenshots"配下固定だった。
このコミットでスクショ保存のディレクトリの設定が変更になって、「Capybara.save_pathがあればそれを優先して使う」になった。
require 'capybara/rails'すると Rails.root.join('tmp/capybara')がCapybara.save_pathに設定される(これはずっと前からそう)
- capybara/rails
このあわせ技により、Rails7にアップグレードするとスクショの保存先が"tmp/capybara"に変わってしまう
"tmp/screenshots"にしたい場合は、require 'capybara/rails'しているところよりも下でCapybara.save_path = Rails.root.join('tmp/screenshots')で :ok_woman:

2021-12-16

Tower Git Clientでgitのhookを動かす

gitの操作にTower Git Clientを使っています
- 一部の行を選択してstagingしたり、コミットを移動させたりsquashしたりするのがCLIより楽
が、PATHの設定がないのでhuskyなどを使っているとコミット時にエラーになりコミットできない、ということがあってストレスが溜まっていました
ちゃんと調べたらCommand Line Environment | Tower Help でPATHなどの環境変数を設定できるぞ、とのことでその通りしたら解決した
よかったよかった

2021-10-28

LeanとDevOpsの科学を読んだ

LeanとDevOpsの科学［Accelerate］テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ | Nicole Forsgren Ph.D., Jez Humble, Gene Kim, 武舎広幸, 武舎るみ | 工学 | Kindleストア | Amazon
1章をざっと読んで、2,3章はほとんど飛ばしてしまった
高いパフォーマンスを出している企業はこういうことをしている、というのをちゃんと統計とって因果関係があることを調べているのが偉い
エンジニアとしては肌感覚としてそうだろ、と思っていたが数値的根拠は出しづらいやつに対して根拠を与えてくれている
- どういう調査方法をしたか、というのは本の中に書いてあったけど、具体的なデータは本にはないので(たぶんめっちゃ膨大なので本には載せられないだろうが)どこかで見れたりするのだろうか…
ソフトウェアデリバリのパフォーマンス評価基準
- デプロイの頻度
- 変更のリードタイム
- MTTR
- 変更失敗率
  - この基準は無視してもいいんだったかな…
↑のソフトウェアデリバリのパフォーマンスが上がると組織全体のパフォーマンスが上がる
関連するプラクティスを実践し、ケイパビリティを高めることでソフトウェアデリバリのパフォーマンスが上がる→結果的に組織全体のパフォーマンスが上がるというロジック
この本の内容を活用して、いかにして組織のパフォーマンスを上げるとよいか
- 自分が組織の偉い人であれば、単に評価基準を計測できるようにしてその評価基準を良くする施策を打てば良い
- 偉い人でなければ、偉い人に働きかけをする必要がある
  - ここが難しいのは以前と変わらないが、少なくともこの本によって話に根拠を持たせられるので前よりは働きかけがしやすくなっている、というのはありそう