Realizing that the majority of clever Keynote slide tricks I’ve accumulated over the last 15 years have been to make intangible topics feel more concrete and easy-to-follow. Because my next talk is essentially an annotated demo of real, working software, I’m finding myself discard most of my own tropes to save time.
Why should you come to my Rails World talk about building an app? Look no further than my latest credential. Hotwire user of THE WHOLE MONTH.*
*Apparently there are actually two of us.
You’ll never guess whether or not I am finding NONE, A FEW, or EXTREMELY MANY bugs in the Squarespace website editor.
Folks should check out this Ruby on Rails thing. I’m getting an awful lot done!
You know a SaaS product has really "made it" when the the home page's Login link is as prominent as the Sign Up button.
Surprisingly few programmers know this, but mutable and immutable actually mean the same thing.
Yes, this is a link post to my own post on switching Rails system tests from Selenium to Playwright, which is newer, faster, and by all accounts I've ever heard from anyone who's used both of them: better.
Since posting this, I have heard several complaints from skeptics, all along the same lines of: how could Playwright possibly be less flaky than Selenium? After all, the tests are written with the same Capybara API. And, being the default, Capybara's Selenium adapter has had many more years of bug fixes and hardening. To these people it simply does not make intuitive sense why Selenium tests would fail erratically more often than Playwright.
Here's my best answer: Playwright is so fast that it forces you to write UI tests correctly on day one. Selenium isn't.
Because UI tests that automate a browser do so asynchronously through inter-process communication, the most common way for tests to be susceptible to non-deterministic failures is when that communication is meaningfully slower than the browser itself under certain circumstances and faster in others.
Two of the most common examples follow. (I use the word "page" below very loosely, as it could apply to any visible content that is shown or hidden in response to user action.)
A script that finds a selector that exists both before and after navigation:
.foo.foo element.foo.foo before Page B loads, causing it to fail.foo, and continue successfullyA script that fails to properly wait:
Counter-intuitively, the faster your browser automation tool is, the more often the test will fail during race conditions like those above and those failures are a good thing.
If you select something that exists on both pages or without properly waiting, Playwright will almost always be faster than your app and you'll simply never see an improperly-written test pass, either in development or in CI. Instead, you'll be forced to write the test correctly the first time.
Selenium, meanwhile, is so slow under so many conditions and in so many environments that it's not uncommon at all to write a passing test full of race conditions like those above, have the test pass every single time you run it locally, but then see it fail some of the time in CI. Worse, as time goes on your code will become more complex and both your app and your tests will become slower in their own ways. This can lead to apps that had previously been fast enough to always pass in spite of any race conditions to begin failing with alarming frequency years later.
And of course, when that happens, you're in a real pickle. Erratic failures are inherently hard to reproduce. And if a test has been passing for years and is suddenly failing, you aren't likely to remember what you were thinking when you wrote it—meaning that if you can't reliably reproduce the failure, you're unlikely to be able to fix any such race conditions by just looking at the code.
Anyway, that's why.
Switching an existing test suite from Selenium to Playwright won't magically fix all the flaky tests that Selenium let you write by virtue of its being slower than your app. In fact, the first time you run Playwright, you're likely to see dozens of "new" errors that have in fact been hiding in your tests like land mines all along. And that's a good thing! Fix them! 🥒
Anyone have experience building web apps that stream video for the web over AWS Cloudfront? Would love any advice on performance and reliability. Email me! justin@searls.co
Writing Becky a feature for managing frequently asked questions but halfway through my editor crashed and I lost all my work so now I’m fresh out of faqs
When developers have to keep thawing and fixing code during a code freeze, it can cause code freezer burn, which can be REALLY costly to fix
In theory, I really like using generated columns in Postgres (which Rails supports with t.virtual migrations), but in practice it creates too many situations where persisted Rails models lie to you because generated columns are only updated if you think to call reload
Just published standard-rails@1.2.0 - is it finally ready for production? Apparently, yes, because I am finally running it in production github.com/standardrb/standard-rails
Unsure why this is necessary when so few people see your Threads posts as it is techcrunch.com/2024/08/24/threads-confirms-it-is-experimenting-with-ephemeral-posts/
It is me, I am back! And after working too hard and becoming too dull I'm finally done* with that big app I've been working on.
I'm running behind on e-mails and need your best and worst takes for the next episode: podcast@searls.co.
Find out what that asterisk refers to below:
I got so frustrated getting the runaround from my ISP that I filed an FCC complaint and… holy shit.
Government in action.
TIL that inline JavaScript handlers actually define an event variable for you:
This actually works:
〈a onclick="event.preventDefault(); this.closest('dialog').close()"〉
Maybe everyone else knew this, but it took me over 25 years apparently.
One thing I really dig about the AI/LLM boom is that it’s the first time since the 90s that otherwise "non-technical" people in my life have had any reason at all to get excited about computer-ass computing.
Seeing friends and family get interested in how ChatGPT works while improving at how they use it is way more gratifying than the last 15 years of the industry merely training the world how to doomscroll.
I wrote this over the weekend. Whether you use Stimulus or just like reading discussions of nuanced code organization and design trade-offs, I hope you’ll enjoy it justin.searls.co/posts/a-decoupled-approach-to-relaying-events-between-stimulus-controllers/
Part of the allure of Stimulus is that you can attach rich, dynamic behavior to the DOM without building out a long-lived stateful application in the browser.
The pitch is that each controller is an island unto itself, with each adding a particular kind of behavior (e.g. a controller for copying to clipboard, another for displaying upload status, another for drag-and-drop reordering), configured entirely via data attributes. This works really well when user behavior directly initiates all of the behaviors a Stimulus controller needs to implement.
This works markedly less well when a controller's behavior needs to be triggered by another controller.
