Managing your own Temporal cluster is a daunting task. Between the four core services, the myriad of metrics to monitor, and a separate persistence service, it's a sizeable undertaking for any team. This post begins a new series that will review the work involved in hosting Temporal yourself and try to demystify it.

There’s a growing demand to create more polished user experiences in increasingly complex web applications. Making the jobs of QA engineers more important - and more difficult - than ever.

Software developers are superstitious out of necessity. Given the task of keeping a software system functioning properly without the ability to reason about or memorize its entire operation, developers have a healthy fear of unexpected breakages. We often raise the steps intended to mitigate breakages to the level of ritual. One of the most notable manifestations of superstition in software is legacy code.

Creating reusable components is often hindered by excess code accounting for each use case the components need to support. For example, a dropdown that supports text, links, buttons, and even complex components, or a text component that supports multiple different types of HTML tags, in addition to reusable components as well. In both cases, a variety of props will exist for each type of component we pass in that may need to be shared between the parent and child.

You've probably heard of a content management system (CMS), even if you’ve never used one. In short, a CMS is a piece of software that allows users to create, manage, and share website content without knowing how to code.

Most applications leverage API requests to fetch data. Considering data fetching is crucial for Angular testing. Consequently, it's common to include HttpClient in your unit tests.