I recently ran into an issue where the Intercom chat widget was interfering with my Playwright integration tests. The widget was opening up and keeping some key elements from being clickable. A user could have easily dismissed the widget, but I didn’t want to bother dismissing it within Playwright. I couldn’t find any particular guidance on how to keep the widget from loading in the usual places on the web, so I had to come up with my own solution.
What I ended up doing was intercepting all outbound requests Playwright was making and skipping any that called the Intercom domain.
I created this helper function:
And then called it in the test files that were affected:
It shouldn’t be too difficult to modify this to also block chat widgets from other vendors like Zendesk or Drift.
I recently finished a book by Rolf Dobelli titled Stop Reading the News. Dobelli makes a compelling case to switch from daily news consumption to reviewing news once a week or not at all. As Dobelli argues that there’s not a lot you can do about the news literally as it happens, so why amp up your anxiety by consuming it every single day?
Now, I’m not ready to totally abandon the news — especially these days with COVID-19 raging in my home country — so I’m trying out the once a week strategy with a subscription to the print edition of The Economist. They give you the week’s news in a relatively condensed format that you can read in one sitting. Also, since it’s the print edition, I’m not getting lost following links all around the web. I’m also keeping tabs on COVID-19 cases in my area with tools like then Google News Coronavirus map, and as Dobelli suggests, I still read news about tech and development that have an impact on my career.
Stop Reading the News is a short book and I’d suggest giving it a read if you’re at all interested in understanding Dobelli’s reasoning for cutting back on the news and strategies for how to replace news in your life.
Sites that are served statically (meaning they aren’t backed by a scripting language or a database) have big advantages in terms of speed, simplicity, and security. But as Leon Paternoster notes, the definition of static sites is changing, and we’re losing speed and simplicity in the process.
Under the traditional static model, the heavy lifting of building pages from includes and local or external data is done when the website is compiled into flat HTML files, whether that’s on a PC or a server. This happens out of view (hence Jekyll, incidentally), completely separately from any user involvement. Javascript is used to enhance UI, perhaps through offering sorting or filtering functions. All the user does is download the HTML file and its assets.
Under a newer model (which even has its own Netlify-created brand name of JAMstack) much of this heavy lifting is moved to the user’s browser. Websites are created as SPAs, where HTML, CSS, data and javascript are downloaded in one bundle and the javascript creates pages based on user interaction.
The issue with a “newer model” static site is that the JavaScript required to render a page is often so large and complex that it can take a significant amount of time to download and then execute on a device. That could be a recipe for frustration when visitors have spotty internet connections or are using relatively slow phones or laptops.
I’ve been a Mac user since right before the transition to Intel in 2006. Over the years I’ve collected a large number of third party apps that I use regularly for work and sometimes for play. I’ve left default Apple apps off the list, but I use those as well.