jsのArray.prototype.sort()は引数を渡さないと、要素を文字列に変換して比較する

タイトルがすべて。

rubyだと

elements = [100, 99]
elements.sort #=> [99, 100]

のようになるのでjsでも同じ挙動を期待するけど、タイトルの通りの仕様なので次のようになる。

const elements = [100, 99]
elements.sort() #=> [100, 99]

sortの引数に次のように関数を渡すと期待通り動く。

const elements = [100, 99]
elements.sort((a, b) => a - b) #=> [99, 100]

参考: Array.prototype.sort() - JavaScript | MDN

herokuの無料dyno/addon有料化で無料のままでいるDBやredisは削除される(が、サポートの人に頼むと復旧してもらえる)

タイトルがすべて。

For non-Enterprise users, hobby-dev databases will be deleted in accordance with the Heroku Documentation starting November 28, 2022.

Removal of Heroku Free Product Plans FAQ - Heroku Help

ちゃんと書いているのに見逃していました…＞＜

DBの中身がなくなると困るのでサポートに連絡すると、すぐにレスポンスが来て対象アプリケーションやDB名などを聞かれ、返したらシュッと復旧してもらえました。30分くらいで解決してすごい！

■

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の実装で問題ないぞ、というのを確認できた

参考

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

require 'zlib'
Zlib::InProgressError

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

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

2024/06/28追記

require 'capybara/rails'としていなくても、rspec-railsを利用していたらそこで暗黙的にrequire 'capybara/rails'されている模様

rspec-rails/lib/rspec/rails/vendor/capybara.rb at main · rspec/rspec-rails

Tower Git Clientでgitのhookを動かす

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

LeanとDevOpsの科学を読んだ

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