はてなブックマーク

幸いに登壇のチャンスがいただけたので、Kaigi on Rails 2023に現地参加してきました。 E2E testing on Rails 2023 by Yusuke Iwaki - Kaigi on Rails 2023 2年前の「システムテスト解剖学」という発表の続編的な位置づけで、RailsのE2Eテストを取り巻く技術の解説に徹する発表でした。 自分の発表のスタイルとして、「◯◯したらいいよ」「△△ライブラリ使うといいよ」系の発表にはしたくないというちょっとしたこだわりがあり、とはいえ今回の発表は手を抜くと「Playwright最高だよ、めっちゃいいよ」になってしまうので、注意深くストーリー展開を練って本番に望みました。 Node.jsベースのテストランナーを話す必然性 Railsで何をしたら幸せになれそうか？の定義 じつはあれもこれもしなくても、1個だけ仕組みを作ればいいんだ

かれこれ１年半くらい、Ruby向けのブラウザオートメーションツールをいろいろ趣味で開発している。 特に中身はないが、これまでやってきたことを少しサマリ。 はじまりはRubykaigi2020 思えば、開発を始めた動機は非常に不純で、「Rubykaigi 2020になんでもいいから出てみよう」だった。悪く言えば、ただ目立ちたいだけ。Puppeteerはなんとなく好きで触ってたので、「Rubyに移植したらなんかすごいんじゃね？」くらいの気持ちで実装を初めて、手応えがあればRubykaigi2020のCFPを出そうとしていた。 ところが、そうは簡単にいかなくて、WebSocketとasync/awaitで完全に手詰まりとなる。 yusukeiwaki.hatenablog.com それでもconcurrent-rubyとお友達になり歩み直して、最初のリリースは2020/04/05だった。全然CF

Playwrightのリリースノートに、気になる記載がある。 Release v1.4.0 · microsoft/playwright · GitHub 英語が苦手でも読めるよう、みんな大好きdeepl翻訳をかけておこう。 爆速の多言語展開スピードを支える何かがあるらしいことはわかる。 ただ、具体的にどういう仕組みで動いているとか、どうやればクライアントが実装できるよとか、そういう情報はドキュメントには一切書かれていない。 さすがマイクロソフト。 なので、いろいろソースを読んで調べた＆実際にRubyからPlaywrightを使うPoCを作ってみた。 PlaywrightはServer/Clientモジュールに分かれている 結論から言うと、 microsoft/playwright (TypeScript版)にはServerモジュールとClientモジュールの両方が含まれている ただ、RE

macOS Big Sur betaは初期から使ってみてたんだけど、beta6にしたらDockerまで使えなくなってしまったので、衝動的に まったく新しいmacOS Big Sur betaでは Homebrew→使えません Androidエミュレータ→使えません Docker→使えません VirtualBox→使えません 早く直ってくれないとエンジニアリング活動できないぞ— Yusuke Iwaki (@yi01imagination) 2020年9月17日 こんなTweetしたら思いの外リツイートされまくってしまった。 事実ベースで情報を知りたい人向け に、自分のマシンで起きてることを、雑ではありますがまとめておきます。 （2020/09/18 14:00追記: beta7にするとDocker使えるようになっていました ） 動作環境 2019のMacbook Pro 15インチ。Moj

RubyKaigi2019まであと1ヶ月ですね。今年は福岡開催です。 これを書いている私はどういう人かというと、川崎に長らく住んでいたけど諸事情により1年前から福岡に住み始めたエンジニアです。まだそんなに福岡のことは知りません。逆に言うと、「東京のときのここがよかったなー」「福岡のこのあたりはまじで住みやすいポイントだわー」みたいなのが新鮮なのではないかなーと思います。 yusukeiwaki.hatenablog.com とりあえず関東のエンジニアのみなさんに、福岡をより知っていただきたいなーくらいで書いてます。 あらかじめ書いておきますが、かなり偏見に満ちたガイドですｗ "コンパクトシティ" 福岡市は、都市圏がとても小さい。完全に自分のイメージだけど、 このくらい。 比較のためにいうと、東京だとこれがエンジニアのみんなの馴染み深い 渋谷と恵比寿＋500mくらいの圏内くらい。 交通手段に

なんとなく最近いくつかのWebサービスを触って「あ、こういう作りしちゃうとしんどいんだな・・・」というのが少しだけ分かってきたので、ほんとになんとなくメモっておく。 「下書き」「公開」をstatus=draft/publishedとかpublished=true/falseで表現してはいけない class Article < ApplicationRecord belongs_to :user scope :draft, ->{ where(published: false) } scope :published, -> { where(published: true) } def publish! update!(published: true) end こういうモデルを作ってしまうと 下書きと公開後で「見ることができる人」が異なるべきなんだけど、ふとした拍子に Article.find