ディスプレイをどう配置するのがベストか

今はLGの27インチのディスプレイを二台、一台を縦に、一台を横にして運用しています。

昔は二台縦にしていたのですが、最近google meetやzoomなどで画面共有する事が増えたので、横にしておいたほうが参加者に優しいぞ、というのと横幅が広いことが前提としたwebページが時々ある*1のでそれで一台横にしています。

f:id:willnet:20210726110511j:plain

二台のディスプレイを上下に配置し、それぞれ横にするというのも魅力的なのだけど、今のディスプレイアームではそれができないやつなのでどうなんだろうなーとなっているところです。

みなさんのかんがえたさいきょうののディプレイ配置、もしよければ教えて下さい(\( ⁰⊖⁰)/)

*1:横幅が狭くてもちゃんとみれるwebページ、もっと増えてほしいぞ…

docker-compose runでbashを起動したら何故かctrl-hなどのコマンドが期待通りに動かなくなった

関連Issue

compose run does not forward signals · Issue #1461 · docker/compose-cli

↑が対応されたらdocker-compose 2系でも問題なくctrl-h打てそう

docker環境でシステムテストを途中で止めてブラウザで画面を確認する

savanna日報から改変してブログに書く試み

ref: slackのhuddle良さそう - savanna.io

  • Railsがdocker環境でなければheadlessではないchromeを使うのが楽
  • Railsがdocker環境であれば、remote debuggingを有効にする
    • remote-debugging-port=9222
    • remote-debugging-address=0.0.0.0
    • この2つをオプションにつけてheadless chromeを立ち上げる
  • もちろんdocker-compose.ymlで9222ポートにアクセスできるようにしておく必要がある
  • binding.pryなどのブレークポイントをしかけてテストを実行し、ブレークポイントで止まったらおもむろに localhost:9222 にアクセスするとその時の画面が表示できる
  • このとき、テストを実行する環境をdocker-compose runで実行していると表示できない
    • デフォルトだと、たとえdocker-compose.ymlに適切にportsの設定をしてもホスト側からは接続できないという仕様
    • docker-compose upしている状況でdocker-compose runでワンタイムなコマンドを実行するときにportが被ってエラーになる、というのを防ぐため
    • ref: https://github.com/docker/compose/issues/1259
    • docker-compose run --service-ports hogeのようにservice-portsオプションを付けるとホストからつなぐことができる

脆弱性情報をどこまでどうやって共有するのが良いのか

脆弱性が見つかって、対応パッチが入ったgemの新しいバージョンがリリースされるということはよくあります。そういうときに僕は内容を把握して「こういう脆弱性があるので早くバージョン上げましょうね」と各お手伝い先に共有しています。

各お手伝い先にとどまらず、ブログに書いて広く周知したほうがいいのかな…と思いつつしないほうが良い理由もあり、現状では公開しない、を選択しているけどどうするのがいいんでしょうねえ…。

なぜ公開しないのか

  • どれくらい危険な脆弱性なのかわかりやすくするために、具体的な攻撃方法を調査できる範囲でまとめ共有することが多い
  • そのため、これを公開すると悪意を持っている人にとっての便利情報になってしまいそうだなあ…と感じる
  • ので公開をしないという選択をしている
  • しかし公開したほうが良い、という理由も思いつく
    • 本当に悪意を持っている人は僕が公開するまでもなく攻撃情報を自ら得るはず
    • 「これくらい危険な脆弱性なんですよ」というのを周知すると対策を取る企業は増えそう
      • とはいえ基本的にはセキュリティアップデートをする企業はするし、しない企業はしないだろうと思うので公開するメリットをデメリットが上回りそうではある
  • 悪意を持っていない人にだけいい感じに情報を届けられるのがベストなんだけど、だれかいい案ないですかね…

n_plus_one_controlはrequest specで使うのが良いという話とrequest specでログイン後のリクエストを投げるための方法について

savanna.io の日報からの転載。ちゃんと整形したり説明詳しく入れてメインのブログで公開しようと思ってたんだけど時間がなさすぎた

  • palkan/n_plus_one_control: RSpec and Minitest matchers to prevent N+1 queries problem
    • N+1をテストで検出できて便利
    • 実際に同じテストを、DBレコード数だけ変えて複数回実行して発行したクエリ数を比較する
    • クエリ数が違うとN+1では？となりテストを失敗させることができる
  • N+1が起きるのは実際のユーザがアクセスしたときなので、システムスペックでは、と思いそうしていた
  • しかしsystem specだと、ajaxを利用しているページを表示したときにタイミング次第でajaxリクエスト処理時のSQLを計算に入れてしまいテストがコケる
  • 具体的にはturbo-frameで遅延ロードを追加ところこれが発覚したけど、turbo-frameに限らずajax使っているページでは起こり得る
  • 他になんかいい方法あるかな、と考えたがN+1をチェックするところはrequire specを使うのがいいんじゃないか、という結論に達した

request specでログイン後のリクエストを投げる

  • ↑ということでrequest specを久しぶりにちゃんと書こうと思ったらログインどうやるんだっけ？となったのでまとめた

1. allow_any_instance_of

  • 手っ取り早いがハック感ある
before do
  allow_any_instance_of(ApplicationController).to receive(:current_user).and_return(ログインさせたいユーザオブジェクト)
end

2. session

get root_path
session[:user_id] = user.id
get after_login_path
  • これはうまく動かなかった
  • 最初にroot_pathにアクセスしているのは、sessionメソッドが@requestが存在している前提で書かれており、最低一度アクセスしないといけないため
  • 昔はこれで実装していたような記憶がうっすらあるが、Rails5からはできなくなったのかも

3. ログイン用のリクエストを事前に投げる

  • request specもE2Eの一種と考えると、ちゃんとログイン用のリクエストを投げるのがお行儀が良いのでは、という気がする
  • dhhも推奨している方式
  • これはOmniAuthでtwitterログインしている前提
OmniAuth.config.test_mode = true
OmniAuth.config.mock_auth[:twitter] = OmniAuth::AuthHash.new(
  provider: 'twitter',
  uid: idをいれる,
  info: {
    nickname: ユーザ名をいれる
  }
)  
post '/auth/twitter'
follow_redirect! # OmniAuthはリダイレクト後にログインセッションを生成しているのでこれがないとログインできない

type="date"なフォームをcapybara+chromeでテストするには

  • type="date"なフォームは現時点ではsafari以外のブラウザはカレンダーっぽい入力に対応している
  • こんな感じになる
    • f:id:willnet:20210412183642p:plain
  • 入力もtype="text"のときとは違うようで、普通にfill_in '日付', with: '2021-01-01'のような入力だと期待通りの日付が入力できない
    • なぜか10101-02-02みたいになってしまう
    • テストが失敗する
  • capybaraはこれを回避するためにjsで日付を埋めることをしている。これは入力がString以外かつto_date?に 対応しているオブジェクトが対象。なのでfill_in '日付', with: Date.new(2021, 1, 1)`のようにしたところテストが通った