Forem: Nočnica Mellifera

Filling Out Forms with Playwright: Choosing Between `fill()` and `pressSequentially()`

Nočnica Mellifera — Tue, 30 Sep 2025 16:58:17 +0000

Filling out forms is one of the most common tasks in web automation and testing. When using Playwright, you have two primary methods for entering text into input fields: .fill() and .pressSequentially(). While both accomplish the same basic goal, choosing the right method can significantly impact the stability, realism, and effectiveness of your tests.

The Default Choice: `locator.fill()`

For most scenarios, locator.fill() should be your go-to method. It's fast, efficient, and simulates what happens when a user pastes text into a field.

When to use fill():

Simple text inputs without dynamic behavior
When you need to quickly populate form fields
For basic form submissions where typing simulation isn't critical

// Simple and efficient for most cases
await page.locator('#username').fill('testuser');
await page.locator('#email').fill('user@example.com');

When to Switch to `pressSequentially()`

The community discussion reveals several specific scenarios where pressSequentially() becomes necessary:

1. Testing Auto-complete and Search Suggestions

If you're searching for "Doug Bowser" and want to test the intermediate suggestions that appear as you type "D", "Do", "Dou", etc., fill() won't trigger these incremental updates.

// Triggers search suggestions at each keystroke
await page.locator('#search').pressSequentially('Doug Bowser', { delay: 100 });

2. Triggering Field Validations

Some forms validate input as users type. If you need to test this real-time validation behavior, pressSequentially() allows you to simulate the actual typing process that triggers these validations.

3. Making Automation Less Detectable

When scraping or performing long-running automation tasks, instantaneous text entry can be a telltale sign of bot activity. pressSequentially() with appropriate delays can help mimic human typing patterns.

// More human-like typing behavior
await page.locator('#message').pressSequentially('Hello, this is a longer message', {
  delay: 50 // milliseconds between keystrokes
});

You could even randomize these delay times for multiple form fills.

4. Testing Learning Applications

For applications that grade typing velocity and accuracy, or any scenario where the timing and sequence of keystrokes matter, pressSequentially() is clearly the right choice.

Practical Recommendations

Based on the community consensus:

Start with fill() - It's faster and sufficient for most cases
Switch to pressSequentially() when you need:
- To trigger intermediate API calls or UI updates
- To test real-time validation
- More realistic user behavior simulation
- To avoid detection in scraping scenarios
Use the delay option to control typing speed when realism matters:

await page.locator('#input').pressSequentially('text', { delay: 100 });

Conclusion

While fill() will handle most of your form-filling needs efficiently, pressSequentially() is your tool for scenarios requiring realistic typing behavior. The key is understanding your application's behavior and choosing the method that best matches how real users interact with your forms. Whether you're testing search suggestions, form validations, or simply trying to make your automation more human-like, having both methods in your Playwright toolkit ensures you can handle any form-filling scenario effectively.

The Sub-prime Crisis of Notifications

Nočnica Mellifera — Thu, 15 Sep 2022 15:51:29 +0000

Or, how we’re destroying users’ trust, and how to get it back. Check out the first post in this series as well: Building a Great UX Outside of Your App.

There is a direct connection between all the unnecessary notifications you get on your phone and the sub-prime financial crisis of 2008. The connection is human behavior in a large and anonymous marketplace where bad behavior is rarely punished.

In a recent Hackernews post, I posited the same connection: that apps that send notifications are facing a systemic collapse where users will be so overwhelmed with mass notifications that most of them will opt out entirely. One user responded with a great synopsis of the problem:

Unfortunately if it drives engagement of 2 people at the expense of becoming annoying to one person the app developers will keep over-using notifications.

I’d add one further sad corollary to this observation: as long as other app developers are over-using notifications, it’s irrational for you the app developer not to. As you compete for attention on users’ devices, you will fall behind your competitors if you don’t emit a few notifications a day. So even though your individual action hurts the user experience overall, it can be irrational for you to avoid doing so.

As any fan of financial crises can tell you, the subprime bubble, where lenders created AAA-rated securities out of extremely shaky mortgage lending, was not an evil scheme dreamed up by nihilists. Rather, it was the act of rational people acting in their own best interests. As long as other banks were selling junk securities at high markups, it wasn’t rational for one bank to stop, even when they knew the system couldn’t go on forever. As former Citigroup CEO Chuck Prince infamously said, “as long as the music is playing, you have to keep dancing.”

What the crash would look like

Any time I start a discussion on Reddit or Hackernews about what users want in notifications, most commenters say that they want out of notifications entirely. It was only three years ago that most users got ‘do not disturb’ mode on their phones, and more and more users are deciding to stay in Do Not Disturb forever.

Can notifications ‘crash’ the same way that the mortgage market did? Absolutely. The sequence looks like this:

Increased awareness of unnecessary notifications
Government regulators request that OS producers limit unnecessary notifications
All notifications become tightly restricted
Contacting users via push notifications becomes unreliable
Application developers no longer invest the time in timely notifications
With users no longer expecting notifications, developers are forced to go back to email and SMS to contact users at all

The Prisoner’s Dilemma

John Cassidy in his illuminating book How Markets Fail explains that this pattern is in fact a version of the prisoner’s dilemma. The multiple actors in the market aren’t able to coordinate and they end up choosing options that are individually beneficial, but collectively negative.

The sub-prime crisis nearly crashed the global economy and we still live in its shadow. In the world of notifications: every OS release on our phones further limits how apps can notify us, is a similar crisis coming in the market for user attention?

How we break free

A dire situation, surely, but we can do something about it: collaboration. The prisoner’s dilemma doesn’t work nearly as well if the prisoners can communicate and see each other’s choices. In the case of notifications, all that’s required is that we the creators of applications agree to some simple principles for trustworthy notifications.

This move is not without precedent. Multiple industries decided on voluntary pledges of quality and trustworthiness rather than deal with public ire, choosing self-regulation over government regulation. Perhaps you remember this seal from the childhood newsstand:

Next to Captain America’s adventures and even Grant Morrison’s Swamp Thing, the Comics Code Authority seal was stamped on the cover of comic books for over 40 years. And perhaps you saw another sign of voluntary self-regulation in an air-conditioned theater this weekend:

Neither of these ratings and advisory boards are without their detractors, and as Comic book fans aged and concerns about violent comics diminished, the comics code has disappeared. However, these do show that a lack of public trust can be addressed by an industry-wide standard.

A pledge for better notifications

Folks, I don’t want to be corny, but I do want us to get better. Here we get to the crux: I want us to agree to do better. Here are the principles that can guide better notifications.

One caveat here: this pledge is not about dark patterns or dishonesty. Tricking the user into spending money unintentionally should be covered by generalized ethics, this is about good design principles for developers who want to build trustworthy tools.

1. Be timely

We often feel bombarded with notifications, so a requirement that they come faster can seem counter-intuitive. But it’s critical that you identify when and with what precision your users expect to be informed. A notification that your web service is down needs to come sooner than the first angry call from a user. And a notification about breaking news needs to come before you say something mean about Queen Elizabeth on Slack.

When the Steam Deck inspired a purchasing frenzy, many users complained they got inaccurate notifications, like this classic epoch failure for a user in the UK

Timeliness also means not notifying too quickly. Notifications about how many people liked a cat picture don’t need to arrive at 2:00 AM, they can wait til morning.

The required accuracy of notifications will vary a lot depending on your use case. A scheduling tool like Calendly will need its notifications to arrive on the exact minute we need them to arrive at a meeting on time. A more fun social app probably only needs to send notifications accurately within 30 minutes.

This failure by YouTube may reflect a shift in usage patterns: where previously new and interesting videos didn’t need up-to-the-minute notifications, now users get breaking news and important premieres on YouTube.

2. Be targeted

We may not want our applications to know everything about us, but targeting is a critical part of good notifications. If I ordered Pizza Hut for lunch, I don’t want them notifying me of dinner specials. Look at this not-ideal experience for a user of Accuweather that warned him of thunderstorms…3,000 miles from his current location:

The cut-off text makes the situation worse: it’s easy to assume this is happening in your town!

Some things we’d ideally target in our notifications:

Geography
Time Zone
User’s access level within our service
Where they are in the user journey

3. Be brief

In the example above from accuweather.com, a slightly wordy notification meant the user didn’t see the area affected by the alert. This is one example of a larger problem: a failure to be brief and to-the-point with notification messages.

Since notifications are often shortened when viewed on different devices, be sure to put the most important information first. Journalists would call this the ‘inverted pyramid’ but I prefer to think of it as a special case of little-endian transmission: the least important information should come last.

A special case of the requirement to be brief is digests: ask yourself if your notifications are more meaningful in a group or one-at-a-time. Notifications of individual ‘likes’ on a post is a great candidate for a digest, as is a long conversation thread.

Ideally since you’re following rule 2 and therefore know the user’s timezone, you can dynamically generate digests when notifications would be sent in the middle of the night for the user.

4. Offer (the right amount of) control

Finally there’s control. If I posted every bad example of user preferences for notifications this article would resemble 2000’s Flickr. But:

A classic example is Starbucks’ which, for a time, would only tell you order status if you also accepted spam

So we want to offer users real fine-grained controls. But it is possible to get too fine-grained

If you zoom in, this is every notification setting for Google Maps

The solution when you have too many settings is to offer some grouping, so that users can turn off whole categories.
What unifies these needs?
The common thread between all of these requirements is that they all require technical lift. Timeliness, targeting, brevity (with digests), and user preferences all require that we go above and beyond with our notifications service. A simple bulk send email kicked off by a cron job can’t deliver these features without some very sophisticated and un-maintainable regex. The solution then is to have a notifications service that can offer these features in a lightweight experience for our product team.

In the last article of this series, we’ll cover how you can build a great notification experience without using Courier.

Building a Great UX Outside of your App

Nočnica Mellifera — Wed, 07 Sep 2022 15:58:38 +0000

Recently I had a chance to talk to DevOps
Minneapolis about the true nature of user experience. The audience found this information to be particularly interesting, so I thought it would be helpful to share it with a wider audience. This post will be the first in a series of three posts that will discuss user experience beyond your app’s UI and how you can optimize it.

So where is your user experience? More generally, where does your application happen? For those of us who work in SaaS, the answer is simple: the application occurs inside the application interface. Whether we’re selling business tools or teaching Spanish, the application happens when our users access the UI.

Your UX is inside your application… right?

When we talk about our users having a good experience, that much-vaunted UX, the things we’re tweaking will be inside this application. We have several specialists who worry about user experience. Whether that’s UX thinking about existing users or data and product people making sure the experience for new users is frictionless.

I don’t mean to trivialize this process: it’s much more than tweaking colors and moving buttons by a pixel. Those tasked with UX often have to ask the most basic questions: what do our users want, and what’s the best way to give it to them? This matters because however cool our technology is behind the scenes, if the user doesn’t have a good experience with it, they’re unlikely to return.

This article argues that there’s a more important user experience than the one inside your app. In fact, your app has a whole interface that has more impact on your users, that touches them more deeply than your application interface.

It’s your notifications

This is where your notifications really happen.

Many of our favorite apps largely interact with us through notifications, the examples are everywhere.

Tools for observability and security most frequently have all our interaction starting with notifications. After all, we're probably not checking our APM tools until we know something is wrong.
For social media applications, the best moment we experience with them is seeing that X number of people loved our post.
And for communication and collaboration applications the notifications should have most of the information that people want you to see.

In fact, I’d argue that for many of our most valued tools and services, most of our interface, for good or ill, is through notifications. Notifications bring you into the application. They provide reassurance, warnings, anxiety, or annoying notifications about sales of pizza. Notifications are your application.

I mention all this because I believe that your UX is in danger. Primarily, the experience of notifications has been ceded to teams outside of the product team. Instead of our product team controlling notifications, it’s the operations or marketing/growth teams that control most of the notifications we send.

Let me show you far we have strayed from g-d’s light:

The tale of the signup campaign

The time after a user creates an account is critical for any SaaS tool. Even when users sign up and immediately start using the product, there will be features or extended use cases that we, the developers, want them to try.

Put yourself in the shoes of a product team that’s trying to improve the rate at which new sign ups become committed users. In (almost) all product teams, we’ll realize that we want to get in touch with users after they sign up to encourage them to keep going with our product.

The platform doubtlessly sends a signup confirmation, and we start by tweaking that. We get our new copy and links to the operations team, or platform dev, and they change the post-signup email. But soon, we want more. First off: we don’t really want to email users the instant they sign up, we’d like to wait at least a few hours, to let the platform feel a bit familiar first. Then we’d like to follow up after a few days, and a few days after that.

Even better, we, the product team, would like to customize these messages a bit, depending on their team size, what license they have, etc.
The operations team, who implement all outbound notifications, is rightfully a bit frustrated by this. They’re used to solving bugs and feature requests for the platform, not tweaking an email. Scheduling? Audience customization? This sounds like a job for….

The CRM, where for a time it was good

With all the need for custom targeting, a good first solution is to have a signup get sent as an event to a Customer Relationship Management (CRM) tool like Salesforce. From there, it’s easy to start a ‘signup campaign.’ Since the CRM should know things like the org size and license level of the user, the messages can be nicely customized.

And for a time, it was good. However, trouble starts when we go one step further with targeting and customization.

You see, our signup campaign encourages users to use certain features, like say Reports Export. We want to tell the users about the feature, demo it for them, walk them through the concept. “Please” our emails beg, “export your reports, with the Reports Export.”

This message will seem super weird if the user has already used Reports Export. So we, the product team, go to whomever runs the CRM and say ‘can we cancel this email if they’ve used Reports Export.’ Of course, the CRM doesn’t know that. So we end up back with platform engineering, asking them to send an event to the CRM when someone first uses Reports Export.

The ‘quick and dirty’ solution of CRM wasn’t a durable solution to our problem.

The problem is a ceding of territory

The inherent problem in the scenario above is a ceding of territory by the product team. If the product team wanted to move a button, or change the order of a toolbar, it wouldn’t make sense for the marketing team to say ‘no.’ But when we want to send a correctly targeted sign-up campaign, our reliance on our CRM means Marketing has to say ‘no’ to a better user experience.

Similarly, we wouldn’t let ops or platform engineering keep us from adding a helpful tooltip, but we are letting them keep us from sending a helpful email to the right users.

What we can do to solve the problem

The problem here is a lack of tooling, either external or internal. Every new notification stream requires engineering time, and that means technical limitations keep us from delivering the experience our users deserve.

Whether it’s by using Courier or an internal spike to create a messaging microservice, you want to develop a robust set of features that make it easy to send multiple notification types direct from your platform.

Effortless MongoDB Atlas With Opta

Nočnica Mellifera — Tue, 30 Nov 2021 04:12:12 +0000

*Originally posted on Run[x] Blog

Do you use MongoDB Atlas in your application stack? This post shows you how to use Opta to spin up a MongoDB Atlas database and link it to your application.

Introduction

Opta lets you do infrastructure-as-code where you work with High-level constructs instead of getting lost in low level cloud configuration.
MongoDB Atlas simplifies deploying and managing your MongoDB databases while offering the versatility you need to build resilient and performant global applications on the cloud providers of your choice.
Put together, Opta and MongoDB Atlas abstract away the complexity of deploying your applications and MongoDB databases in a production-ready cloud infrastructure. Together, they will smoothen development experience and improve your product’s feature velocity and reliability.
This blog shows you how to implement a movie search application with Atlas Search and deploy it using Opta. It is based on this blog post; but with some notable differences:

Opta handles the creation of the MongoDB Atlas cluster and database, passing its credentials into the application’s code.
Instead of MongoDB Realm, this example uses a simple Flask API backend and deploys it on to a Kubernetes cluster; don’t worry — you won’t have to spin up the Kubernetes cluster yourself, Opta will do it for you in the cloud of your choice or even your local machine!

Atlas is currently supported in Local and AWS Opta environments. Feel free to open a Github issue if you would like to see support in GCP or Azure.

All the code used in this example is available from here.

Let’s get started!

Setup

Install the open-source Opta cli tool by following the Opta installation instructions. If you are new to MongoDB Atlas you can sign up here. The search application described in this blog can be implemented with the MongoDB Atlas free-tier.

(Git) clone the Opta examples repository and use the Opta files in the opta-atlas-mongo-search sub-directory as a starting point. You will need your AWS and MongoDB Atlas API credentials.

You do not need to configure the IP address in the MongoDB Atlas API key, Opta will do that for you.

Prepping the Opta Environment

After you have downloaded these keys from the AWS and Atlas GUIs, set them as environment variables in the terminal shell where you plan to run Opta.

Atlas Mongo

export MONGODB_ATLAS_PUBLIC_KEY=”fakeefghij”
export MONGODB_ATLAS_PRIVATE_KEY=”FAKE015e-4503–4f95-f129–543d4e58bsdg”

AWS

export AWS_ACCESS_KEY_ID=FAKEFTRFFSDQAZA
export AWS_SECRET_ACCESS_KEY=FAKEksfja234sadfbjsdfgsdfg34SAD34fd
Next, we create the Opta environment with the AWS EKS Kubernetes cluster, as documented here. You can also refer to the environment example yaml file in the git repository.

Note: If you are only trying this out on your local machine, append the — local flag to all the opta commands so that a local Kubernetes cluster is spun up on your machine rather than the AWS EKS cluster. For local runs as well, the MongoDB Atlas Cluster will still be spun up in the cloud.

Deploying the Application with Opta

Once we have the Kubernetes cluster, we can create the MongoDB application by running opta apply on the opta-mongodb-atlas-search/opta/atlasmongoservice.yaml file. Remember to set your mongo_atlas_project_id in this file before running Opta.

First, lets create the docker image that contains our application code:

in the opta-examples directory cloned from Github (https://github.com/run-x/opta-examples.git)
docker build -t mongoapp:latest ./opta-atlas-mongo-search
Then,

For aws

opta deploy — image=mongoapp:latest -c opta-examples/opta-atlas-mongo-search/opta/atlasmongoservice.yaml

OR, For local

opta deploy — image=mongoapp:latest — local -c opta-examples/opta-atlas-mongo-search/opta/atlasmongoservice.yaml
After a few minutes, the application will be running against the new MongoDB Atlas cluster.

Sample Data and Atlas Search Index Setup

Before you can use the application, follow steps 1 and 2 in the original MongoDB tutorial in order to load the sample data and set up the search index in the Atlas database (Although you don’t have to create the cluster, Opta will perform that step). After you have created the MongoDB Atlas search index, wait for a few minutes before going to the next step as the index is built in MongoDB Atlas. Opta will also set correct firewall rules inside MongoDB Atlas so that your application’s IP address(s) can connect to the database.
Once you are done, run opta output to get the AWS ELB endpoint url and point your browser to the address (or to http://localhost:8080/ in case you are using Opta Local); You should now be able to search the movie database like in the screenshot below.

Movie Search Sample Screenshot

If you want, you can use Opta to add TLS to serve the application over HTTPS on your domain!

Conclusion

And there you have it, a web application (Flask API+SPA) using MongoDB Atlas deployed in minutes with Opta.
We were able to deploy the application to a SOC-2 compliant AWS EKS Kubernetes cluster and spin up an Atlas database that automatically connected into our Flask application. All with a couple of simple Opta infrastructure-as-code yaml files and without diving into the nitty-gritties of low-level terraform AWS constructs. Spend less time wrestling with your infrastructure and more time with your application!

I can't believe you're not adding observability

Nočnica Mellifera — Wed, 27 Oct 2021 23:29:08 +0000

cover image by uppsa uppsa

I want to talk to you about observability, the art of understanding errors and performance of your technology stack by implementing monitoring and some kind of tool to view that monitoring.

Listen, if you're making money as an engineer in the tech industry, you're doing a good job. Functional? Object-oriented? Microservices? One big scary monolith?

If what you do is paying for groceries and keeping a roof over your head then it's good code, good architecture, and you have nothing to apologize for.

if this thing pays the bills it's good technology

So when I say 'I can't believe you're not doing observability' it's not about whether your technology is good in any absolute, Manichean sense. I completely understand how observability can seem like a reach goal, a nice-to-have, something that might be useful in other shops but not here, always moved to the next sprint.

But I don't know how you're not stressed out all the time without observability.

Like, what happens when the site goes down late at night? I've been on teams without any kind of standardized monitoring so I know what happens: the best operations person you have gets woken up. If she's unavailable or can't figure it out then everybody gets woken up until someone finds the problem from scouring logs, reverting changes, or testing the system by brute force.

And I've also been in teams where performance trends were invisible, so it was impossible to explain to our PM's why we needed 2 weeks to handle tech debt.

So I think observability is something everyone should be doing. DevOps in its purest form. A concern shared across all technical roles and appreciated by management.

I cannot bring you to this promised land of restful nights and pretty charts, but I can show you how to get there. New Relic can monitor dozens of services using a free tier account, and our free conference next week can show you how to monitor everything from front-end React to Kubernetes clusters.

Register for Data Nerd Days November 3rd, I'll be talking about monitoring serverless. As of the time of writing this article, the next few hundred registrants will get sweatshirts.

If you don't use New Relic use another tool, but for all love do add some observability to your stack soon.

K8s Pods: Image tags vs. Digest

Nočnica Mellifera — Wed, 27 Oct 2021 17:41:03 +0000

Image tags are a common source of frustration with the management of Kubernetes pods. How many times have I seen a question like this

I am unable to see my changes, even though I am using the referencing the image using the Correct Tag.

Or even worse:

I haven't changed the Referenced for the Image, but its behavior changed

These are normal problems to face do the basic design of Docker's image management.

But before diving in, let's see thee terminology that we'll be talking about.

Image Tag

Human understandable reference to an Image used to convey information about that variant. An image can be tagged with multiple tags and can be referenced using any.

Properties:

Mutable
Unique (i.e., the same tag can be used on multiple Images and will reference the last image that was tagged)

Image Digest

Hash reference to an Image.

Properties:

Immutable
Created when pushing an Image to the Repository for the first time.

General Practice

Programmers tend to reference the Images using the Image tags, for the obvious reason of getting a better readability, but in doing so, an important blind spot is missed: an image I1 referenced at time T1, may refer to image I2 at time T2.

This generally happens when the Programmer is referring to generic tags such as latest, or can happen due to Human error, when you end up tagging Image with an already used Tag.

Use Cases

Using latest to point to latest version always. Some other self-explanatory tags like qa / dev / prod, versioning tags like x.y.x for maintaining versions.

Non-deterministic Deployment

When using Image tags for referencing the Image, there is no guarantee that the Tag would refer to the expected Image, because of Tag Mutability.

Another defect with the non-deterministic deployment is some infrastructure tools which are dependent on the Stage Changes, will not be able to detect the changes when using generic tags and no versioning, or if due to a human error of mutating the tags.

In order to avoid Non-Deterministic deployment, we should use Immutable Image Identifier Image Digest should be used. But this way, we lose the Human readability. In order to have Human Readability, as well as Deterministic Deployment, we can refer to the Image using both Image Tag and Image Digest. Docker gives us the capability to integrate both and refer to the Image.

Image Reference: <image_name>:<image_tag>@<image_digest>

Deployment Image with Tag vs Digest

Different ways of referencing

Accessing a resource from a collection of similar resources is always easy when there is a versioning attached to it. It helps users to have a better control the specific resource that they are using. This is useful when versioning attached to the resources is immutable. But at times, situations arise where one wants to have even more readability, for ex., using the latest version ever of the resource every time or raising a small patch so that it reflects in the version. In such cases, we would require the tags to be mutable.

This is the usability around which the K8s Pods were build. Having mutable tags gives the ability to have named versions, something which makes a lot of sense because things are kept easier on the pipelines, like take the latest image, use the dev image, or maybe when a fix is so small that it doesn’t require a version update.

So, now that the versions, a.k.a., tags, are mutable. So, does that mean that is nothing immutable that can be used to get the same Image again and again. This is where the Digest comes into the picture. This is a hash key that is created based on what all base images are used for constructing the image and this is unique for every different image. Digest can be used to reference the same image again and again.

Now let’s get into some techie stuff

Why are tags important?

Tags are human understandable reference to an Image used to convey information about that variant. An image can be tagged with multiple tags and can be referenced using any. Importantly, a tag can be changed to different images.

What is Non-deterministic Deployment?

When using Image tags for referencing the Image, there is no guarantee that the Tag would refer to the expected Image, because of Tag Mutability.

This drawback is for the Infrastructure Tools, which depend on State Changes, as the tools will not be able to find the difference in the state, if the Tag refers to a different image or not.

So, how do we make this deterministic?

In order to get the best of both the worlds, that is human understandable reference as well as deterministic deployments, there needs to be a Dynamic Mapping between Image Tag and Image Digest which can be used when deploying images. While pushing to a repository, we can tag the image and then once the digest is created, use that to deploy the images.

How can OPTA help?

What is Opta?

Opta is a platform for running containerised workloads in the cloud. It abstracts away the complexity of networking, IAM, K8s, and various other components - giving you a clean cloud agnostic interface to deploy and run your containers. It’s all configuration driven so you always get a repeatable copy of your infrastructure.

How does Opta help?

Deploy option of Opta with an image tag input would automatically create the Dynamic Mapping between the Image uploaded to the Repository and use the Image digest to deploy the Image.

For more information on how to use Opta, use this: https://docs.opta.dev/getting-started/

[Video] Running your cloud locally: Opta's Open source Infrastructure as Code

Nočnica Mellifera — Mon, 11 Oct 2021 18:56:15 +0000

Opta is a way to get started deploying services in the cloud without having to understand the nitty-gritty of permissions and connection settings between components.

In this quick video, Sachin demonstrates how you can run Opta locally before you deploy to AWS.

The goal with Opta Local is to let you preview how your application code is running from your laptop without having to deploy to the cloud for every code change

Can we build a better Terraform? The story of Opta

Nočnica Mellifera — Wed, 29 Sep 2021 12:39:12 +0000

cover image by By Daein Ballard - CC BY-SA 3.0
Managing to distributed systems is... difficult. You can find guides and recommendations everywhere that say if you don't have to do a distributed workload you shouldn't.

An article from last year by yours truly argued that containers and container orchestration have very different futures: It makes sense that almost everyone will be working with containers in the future, but it's not as clear that container orchestration knowledge will be de rigueur.

// Detect dark theme var iframe = document.getElementById('tweet-1358307866961084422-274'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1358307866961084422&theme=dark" }

As we've faced this complexity of modern distributed workloads a number of companies have tried to make this work easier. These tools tend to fall into three categories:

"We have an okay tool, but hire us and we'll deliver your whole cloud"

When tools are sold with strict SLA's and mandatory professional services, you're often really purchasing Kubernetes expertise rather than great software

"Our Tool is Free! (for 90 days)"

Often a partially-open-source-tool that inevitably requires some Software-as-a-Service component to really work, a number of tools will lock you into their platform, never give you all the tools, and rarely offer you any support if things go wrong

Actual Open Source

These are teams releasing tools as Open Source Software that can be used, start to finish, on your own. Multiple teams see the growth potential in Kubernetes and other distributed workloads and just want to grow with the industry. They offer professional services or hosted servers in addition to free tools, but you can do the whole thing start to finish yourself.

While this third option sounds a lot better for the user, it can still hit pitfalls. The industry standard Terraform is currently struggling to keep up with community PRs and is in danger of falling behind users needs.

This isn't a new story: Large-ish companies can struggle to justify the cost of maintaining an open source tool, and once they grow to that medium size it's hard to find the time to maintain a tool everyone wants but no one has time to update.

Trying to build a better Terraform

Enter RunX, a small team focused on trying to build a fully modern tool for deploying distributed workloads. We're a small team of just 8, laser focused on reducing toil for cloud engineers. We just raised 4 million in funding, and we'd love you to try out Opta, the easier way to deploy.

Can Kubernetes Save You Money?

Nočnica Mellifera — Fri, 24 Sep 2021 16:52:49 +0000

cover image: detail from Hieronymus Bosch - Death and the Miser

Kubernetes is not known as a particularly economic option. If you're migrating to a distributed architecture from a simple virtual machine, you're likely to see an increase in hosting costs and hours spent on setup at first.

A recent article on our RunX blog talked about how you can save money using Opta to deploy the same project to AWS you previously would have hosted on Heroku.

I'm curious if you've seen overall cost savings by switching to Kubernetes, either from an older distributed compute tool or a monolithic architecture.

Tesla Bot is a great example of how NOT to develop a product

Nočnica Mellifera — Wed, 22 Sep 2021 19:02:16 +0000

Image by u/Kruzat, available via Creative Commons Attribution-ShareAlike 4.0 International License

As I’m sure many of you have already seen, Elon Musk has announced Tesla Bot, a humanoid robot intended to“automate repetitive tasks”. The CEO announced Tesla Bot not with a working prototype or even a partial proof-of-concept, but with a dancer dressed in a modified morphe suit who “gyrated wildly on stage” before the presentation. The robot has a vague timetable, with Musk claiming a prototype will be out sometime next year, and an ambitious set of (at this point hypothetical) specifications: the ability to not only understand and interpret voice commands, but carry out tasks ranging from factory assembly to grocery shopping. Musk has announced that a universal basic income will be necessary to support the people unemployed by his imagined product.

While claims of this magnitude are pretty rare, the bones of the scenario are pretty universal: the boss overpromises on a product that the actual development team knows will be impossible to roll out by the deadline. So what do you do when your boss overcommits your team to building, say, a fully-autonomous robot that can work at Amazon in one year?

Allison Green of Ask A Manager has advice for pushing back on a boss’s decision. “A good boss does want to know when you disagree with something, especially if you feel strongly and especially if you have information or context she might not have considered,” Green says. She says to consider whether you have information that your boss doesn’t have that might make them reconsider, or when a course of action might have consequences that your boss isn’t aware of yet. Executive coach Daneen Skube also says that you can put the onus on your boss to give you the roadmap to achieving what they’ve come up with. “Don’t let your boss get away with platitudes and grand concepts,” she says. “Keep looking confused as you query him about how to implement his noble goals.”

Green and Skube agree that if your boss decides to keep overpromising, your chances of dissuading them are limited, and you should consider the importance of the issue to you. If you work at a company, for example, that has a history of pushing nonviable products, within that company culture it might not be possible as an individual to “manage up” by correcting your boss--especially if your boss is known to take criticism poorly. An individual who continues to vocally disagree after the boss has shut that disagreement down could come across as hostile, even if their concerns are valid and serious.

When a boss is unlikely to respond well to one person pushing back, another choice is to push back as a group. Green has specific suggestions for how to handle that. She says the important thing is to make sure that you and the rest of your group are on the same page about it, and to address the boss together, rather than appointing a spokesperson. It’s also worth remembering that a particularly self-aggrandizing or hostile boss might try to divide and conquer--it might be worth practicing the conversation beforehand, with one of your coworkers playing the boss.

And finally: if your company routinely overpromises and fails publicly, it might be worth looking for a new job. No amount of prestige is worth the headache of having a boss who chronically oversells and then makes it your problem when the product can’t live up to the hype.

Embrace Remote Work or Perish

Nočnica Mellifera — Thu, 16 Sep 2021 13:34:03 +0000

cover image by Matt.c.28 - Own work, CC BY-SA 4.0

Recently our team at RunX was featured in a piece on remote work that has proven something of a rorschach test: in comments on the article and social media sites like LinkedIn, people have seen remote work as difficult, dangerous, a godsend, the future, or an effect of the pandemic that will soon be shaken off.

I wanted to take the opportunity to talk about how RunX has succeeded by embracing remote work, and why other startups will need to let go of locality if they don’t want to limit their growth.

The Limiting factor in cloud growth: people

In 2018 I gave a few talks about the difficulties in hiring experts in containerization, which included the throwaway line: “talk to any CTO and they’ll tell you that it’s hard to hire qualified people, when’s the last time a CTO complained they couldn’t find enough RAM?”

Sadly that little quip is a bit less timely given the current chip shortage, but even if you’ve been waiting six months for a GPU, the point still stands. Where once hardware purchasing could present a hard limit on your IT Operations growth, now the limiting factor is almost always the trouble of staffing and maintaining a team of skilled operations engineers.

Wait, what does any of this have to do with remote work?
I know this has been a hard year and a half for all of us. And for some of us, part of the pain of this time, along with the constant fear and knowledge that western liberal democracies don’t care about the welfare of their citizens, being cooped up in our homes wasn’t always fun. But for those of us lucky enough to still have jobs, and homes, remote work has meant a major upgrade to a previous commute heavy existence.

As our children return to school we’re able to spend an extra hour with them every single day. And our trips to school can happen with any parent now that we don’t have to get to a downtown office.

Days where you have two meetings, one at 8 am and the second at 3pm, can be spent in relative leisure rather than furtively reloading twitter at your desk. And if a day has more than 8 hours of work stuffed into it, well at least you’re home to have dinner with your family.

But as the pandemic stretches into its second year, people’s lives are shifting more fundamentally. People are re-locating to homes that more suit their daily lives. More than one of my own co-workers has gone from semi-urban wasteland to bucolic bliss, complete with solar panels and a goat herd. Others are living closer to family, while still others are planning multi-year global tours.

As numerous large tech companies prepare to ramp up their long-silent offices, they have little to offer in compensation for these lost benefits beyond K-cups and artisan burritos. Major players like Apple and Facebook have shown more willingness to force their employees to commute. Their confidence stems possibly from the knowledge that, paying the highest salaries in the industry, their employees will need to take a pay cut to leave.

Go Big and Go Home

Now perhaps you see the connection between remote work and the difficulty of hiring and keeping good people. If you are incapable of paying half a million dollars for every engineer as the FAANG companies do, you will be hard pressed to keep them if you insist they fight for domestic real estate in the bay area.

But the most successful teams won’t just say ‘remote OK’ and leave it at that. I’m working next on a piece about how remote teams differentiate themselves. In the meantime, comment down below with what benefits you expect in a remote team.

How to Deploy Wordpress to Kubernetes on AWS

Nočnica Mellifera — Tue, 14 Sep 2021 14:04:27 +0000

Introduction

The first time someone suggested adding Wordpress to the Awesome Kubernetes list, I was surprised! I didn't think of Wordpress as something that needed a distributed workload tool. So many readers mentioned it that I put together this brief tutorial.

This article analyzes available paths for migrating a WordPress website to AWS, and the architecture components for AWS-hosted WordPress. This instruction to covers how Opta can be used to provide shared storage on the AWS EKS platform for a WordPress CMS.

Overview of WordPress

WordPress is a simple (CMS) content management system, a process of posting articles and media to a website. WordPress was born as a blogging platform but has grown to support the creation of all kinds of websites. It is free and open-source. It was launched in 2003. It has mainly two basic elements that are the front end and the back end. WordPress provides a spontaneous user interface for this purpose for show text, images, and other media to the web. Anything users see on the website has been uploaded to the webserver. As of 2021, more than 42% of the top 10 million websites are running WordPress.

Alternatives for WordPress on AWS

WordPress has been developed to combine CMS competence that integrates with modern elastic, scalable, and cloud-native architecture. The WordPress group has attempted to develop modules that enable the creations of WordPress sites that exploit AWS Cloud contributions.

AWS provides a large-scale cloud platform that improves performance, control, scalability, and reliability for WordPress websites. The Amazon web services Elastic Kubernetes Service grant the company to build, manage and scale Kubernetes clusters on AWS cloud or local tools.

There are the following options in AWS when going for WordPress hosting as per utilization cases changes:
a. AmazonEC2 -- The EC2 virtual machine system is the classic way to own your own virtualized server on AWS. But the smooth scaling and automated restarting of instances aren't included

b. Amazon LightSail -- It is simple to apply a single-instance virtual private server that abstracts all instances needed to run a simple workload or quick deployment.

Image Source: https://aws.amazon.com/blogs/

For small WordPress websites, it acts as a perfect starting point that can scale later with its growth.

c. AWS marketplace --It includes different pre-configured WordPress images that can be deployed into AWS EC2 in quick time. That single-click deployments are tailored to unique work and come in an adjustable combination of packages and plugins for efficient use of computing resources.

WordPress Hosting Components

While most WordPress organizations utilize speedy begins to enable automated arrangements dependent on best procedures, comprehend the parts that make up a working WordPress application in AWS cloud.
WordPress app. requires components to perform four functionalities:

Static Host Content
Dynamic host content
Blog/site store content/data
On the file system store uploaded files and images.

Now there we will discuss how above each functionality can be managed for AWS.

Stateless Web Tier

In a stateless web tier, the server does not keep any data from one request to the next. The user needs to do its work in a series of simple transactions, and the client has to keep track of what happens between requests. While sessions are maintained by cookies on the end-user’s web browsers, so the WordPress core is stateless.

Scaling Web Tier

It is defined as having the capability to link resources to a system that increases its performance (decrease output times or increase throughput). The number of compute instances includes by AWS that can be used to evolve single-server applications into scalable architecture.
There are about five main components included by scalable web tier to handle scaling for dynamic content:

Amazon Machine Images (AMIs)
Amazon EC2 Instances
Load Balancing
Automatic Scaling
Health Checkup

Shared Storage

Mostly all WordPress Installation files, and client customizations should be handled in a shared platform as this eases the strain on web servers. Amazon web services having the Elastic File System (EFS) which gives a scalable, highly networked file system for different compute instances.
Data Tier
When the WordPress installation data files and setups are moved into a common Network File System (NFS), and static resources are being served on S3, stateful parts are hosted on WordPress Databases. Amazon Aurora is the top solution for running stateful workloads for AWS applications. Both MySQL and PostgreSQL are compatible with this stage. In Opta we will use PostgreSQL.

What is Opta?

Opta is a stage for running containerized jobs in the cloud. It abstracts away the intricacy of networking, IAM, Kubernetes, and different parts - giving you a perfect cloud skeptic interface to deploy and run your containers. It's all arrangement or configuration driven so you generally get a repeatable duplicate of your foundation.

Setting up Opta

Before starting with WordPress, we need to set up Opta. For this article, we will be used Opta.
To set up Opta, install Opta by using the following command in a Linux distro like Ubuntu.

/bin/bash -c "$(curl -fsSL https://docs.opta.dev/install.sh)"

Set-up environment Creation
An organization like AWS or Azure, we will set up an environment by executing the following commands:

opta init env (AWS)
Creating a file opta.yml to describe an environment that you will create. Using the below command and hit then a description of the environment will start showing and a cluster will be created.
Cluster Creation
Using the below command, we can create yml file that is responsible for the initial configuration for your environment and architecture setup.
cat opta.yml
We have seen the first part we will mention about the AWS region and create account id through AWS console, now the second next part we will link modules through setting up Kubernetes or k8s cluster and created several nodes.

name: aws
org_name: XXXX
providers:
  aws:
    region: ca-central-1 
    account_id: XXXXXXXXX254
modules:
  - type: base
  - type: k8s-cluster
  - type: k8s-base

After that execute the command opta apply
When the above command gets executed, we will create an EKS cluster for you and configure VPC, networking, and different other infrastructure pieces.

Implementing WordPress on AWS using Opta

Kubernetes empowers quick scaling of web applications utilizing on-request Horizontal Pod Autoscaling (HPA) approaches. An increment in workload pushes Kubernetes to plan extra reproductions utilizing extra PODs hosting comparative data content. Kubernetes also utilizes rollback arrangement systems to aid in seamless updates for content, client uploaded files. that is the reason a WordPress hosting application on the AWS Elastic Kubernetes Service improves to implementation of scalable, high accessibility websites.
Now we will learn and understand how to provide shared storage to WordPress sites running on EKS which require access to shared volumes.

Kubernetes Access Mode is a specification of a Persistent Volume that defines how it is mounted on a host. Various storage providers help various capabilities and the mode for each Persistent Volume is set to the specific combination of access modes it supports.
There are four types of access mode supported by Kubernetes:

Read-only Memory
Read WriteOnce
Readwritemany
ReadwriteoncePod

Conclusion

In this article you have learned what opta is and how it is involved with deployment process, and this article explained from basic to the concept behind the deployment of WordPress on AWS using opta. If you have any trouble with the process please comment down below or join the opta slack.

Forem: Nočnica Mellifera

Filling Out Forms with Playwright: Choosing Between `fill()` and `pressSequentially()`

The Default Choice: locator.fill()

When to Switch to pressSequentially()

1. Testing Auto-complete and Search Suggestions

2. Triggering Field Validations

3. Making Automation Less Detectable

4. Testing Learning Applications

Practical Recommendations

Conclusion

The Sub-prime Crisis of Notifications

What the crash would look like

The Prisoner’s Dilemma

How we break free

A pledge for better notifications

1. Be timely

2. Be targeted

3. Be brief

4. Offer (the right amount of) control

Building a Great UX Outside of your App

It’s your notifications

The tale of the signup campaign

The CRM, where for a time it was good

The problem is a ceding of territory

What we can do to solve the problem

Effortless MongoDB Atlas With Opta

Introduction

Setup

Prepping the Opta Environment

Atlas Mongo

AWS

Deploying the Application with Opta

For aws

OR, For local

Sample Data and Atlas Search Index Setup

Movie Search Sample Screenshot

Conclusion

I can't believe you're not adding observability

But I don't know how you're not stressed out all the time without observability.

K8s Pods: Image tags vs. Digest

Image Tag

Image Digest

General Practice

Use Cases

Non-deterministic Deployment

[Video] Running your cloud locally: Opta's Open source Infrastructure as Code

Can we build a better Terraform? The story of Opta

"We have an okay tool, but hire us and we'll deliver your whole cloud"

"Our Tool is Free! (for 90 days)"

Actual Open Source

Trying to build a better Terraform

Can Kubernetes Save You Money?

Tesla Bot is a great example of how NOT to develop a product

Embrace Remote Work or Perish

The Limiting factor in cloud growth: people

Go Big and Go Home

How to Deploy Wordpress to Kubernetes on AWS

Introduction

Overview of WordPress

Alternatives for WordPress on AWS

WordPress Hosting Components

Stateless Web Tier

Scaling Web Tier

Shared Storage

What is Opta?

Setting up Opta

Implementing WordPress on AWS using Opta

Conclusion

The Default Choice: `locator.fill()`

When to Switch to `pressSequentially()`