In this article, we’ll look at some options to help backup/archive Google Keep notes, including a solution I built, called Archiver for Google Keep. I built this tool because I wanted an easy way to back up my Google Keep notes in an automated manner, and existing solutions out there weren’t able to meet the need I have. While Google gives us Google Takeout, an enterprise level Google Keep API, and then there is the unofficial gkeepapi by Kiwiz and built in Python, none of these solutions were able to do what I needed.

emailregex.com maintains a regular expression for validating email addresses. The site claims it’s based on the RFC 5322 specification. The regular expression contains several ASCII control characters. It wasn’t clear what they were used for, and since SonarQube’s static code analysis flags them as unwanted, I did some research to discover what they’re used for and how the regular expression works. After several days of digging into various RFC specs, especially RFC 5322 Section 4 and 4.

Photo by Omar Flores on Unsplash I needed to find a solution to managing git hooks throughout the entire organization. I did some research and didn’t find a solution that met our needs, so myself and a couple colleagues built one. In the later sections of this article, I’ll describe what we did to solve the problem. What are git hooks? First, for those who aren’t aware of what git hooks are, let me take a moment to explain.

This article is about combining container images from various sources and architectures and combining them into a single multi-arch container image. If you’re familiar with docker buildx, then maybe you’ve built multi-arch images before from the same Dockerfile. docker-seleniarm is one example where we use docker buildx to build container images for multiple architectures. In this fork of docker-selenium, we build x86_64, arm64, and armv7l images for Chromium and Firefox on Debian.

Users of Web applications use a variety of different browsers. Neglecting to test an application in one of them may result in lost revenue. Testing in the browsers your users use is important for maximizing revenue. All of our end to end UI tests are running only on Google Chrome. I want to change that and ensure we’re covering more of the browsers used by our users. There was no low-cost method available for testing on Safari in the cloud, and according to browser usage statistics, it’s the browser we should be targeting next.