Video with transcript included: https://bit.ly/2RPikkh
Elizabeth Carretto discusses observability at Netflix and where and how their internal tool, Edgar, comes into play.
This presentation was recorded at QCon Plus 2020: http://bit.ly/3pfdF6I
In this video, I will be talking about problem-solving as a developer.
#problem solving skills #problem solving how to #problem solving strategies #problem solving #developer
The Observer Pattern is at the core of reactive programming, and observables come in two flavors: hot and cold. This is not explicit when you are coding, so this article explains how to tell the difference and switch to a hot observable. The focus is on hot observables. The concepts here are relevant to all languages that support reactive programming, but the examples are in C#. It’s critical to understand the distinction before you start doing reactive programming because it will bring you unstuck if you don’t.
Please support this blog by signing up for my course Introduction to Uno Platform.
It’s hard to clearly define what Reactive Programming is because it spans so many languages and platforms, and it has overlap with programming constructs like events in C#. I recommend reading through the Wikipedia article because it attempts to give a history of reactive programming and provide objective information.
In a nutshell, reactive programming is about responding to events in the form of sequences (also known as streams) of data. Technically, any programming pattern that deals with this is a form of reactive programming. However, a pattern called the Observer pattern has emerged as the de facto standard for reactive programming. Most programming languages have frameworks for implementing the observer pattern, and the observer pattern has become almost synonymous with reactive programming.
Here are some popular frameworks:
ReactiveX (Java oriented – with implementations for many platforms)
The concept is simple. Observables hold information about observers who subscribe to sequences of notifications. The observable is responsible for sending notifications to all of the subscribed observers.
Note: The publish-subscribe (pub/sub pattern) is a closely related pattern, and although technically different, is sometimes used interchangeably with the observer pattern.
Hot observables start producing notifications independently of subscriptions. Cold observables only produce notifications when there are one or more subscriptions.
Take some time to read up about the observer pattern if you are not familiar. If you start Googling, be prepared for many different interpretations of the meaning. This article explains it well and gives examples in C#. This article is another good article on the topic of hot and cold observables.
A hot observable is simpler because only one process runs to generate the notifications, and this process notifies all the observers. A hot observable can start without any subscribed observers and can continue after the last observer unsubscribes.
On the other hand, a cold observable process generally only starts when a subscription occurs and shuts down when the subscription ends. It can run a process for each subscribed observer. This is for more complex use cases.
Hi everyone, in this post, I will share my experience on how to create a custom event service in Angular using **observables **which is based on the principle of observer pattern and is **similar **to the principle of publish/subscribe design pattern.
In observer pattern, an object known as **subject **maintains a record of its dependents known as observers and informs them implicitly whenever there is a state change. Whereas in publish/subscribe design pattern, senders of the messages known as publishers do not send the messages directly to the specific receivers known as subscribers, instead communicate with each other through an **agent **known as **broker **or **message broker **or **event **bus.
In this example, I have created a custom message event service and I will show you how it is being used by other angular components.
Below is the code snippet of the custom message event service file.
In this file, I have created a class called “MessageEventManager” which uses the Observable, **Observer, **and **Subscription **class of **RxJS **library and are the building blocks of our custom message event.
As shown in the code snippet, we have created a **constructor **and **initialized **the class members inside it and is **called **whenever a new **object **is created.
The share() operator inside the constructor is used to **rebuild **a new subject and subscribe it to the source observables whenever a subscription is made after the reference count drops to zero.
The **subscribe(eventName: any, callback:any) **method is used to register the eventName and return the **subscriber **and the **broadcast(event:any)**method is used to broadcast the next event.
The destroy(subscriber:Subscription) method is used to **unsubscribe **the subscriber. This method prevents memory leakage and is recommended as one of the best practices.
Next, we have created a simple app component in angular which uses MessageEventManager class to describe how message event service is used while triggering a demo event from app service.
#observer-pattern #observer-design-pattern #angular #observables
To get fast feedback, ship work often, as soon as it is ready, and use automated systems in Live to test the changes. Monitoring can be used to verify if things are good, and to raise an alarm if not. Shipping fast in this way can result in having fewer tests and can make you more resilient to problems.
Dan Abel shared lessons learned from applying observability at Aginext.io 2020.
Shipping small changes, daily or hourly, sounds simple, but it can be a hard thing to be great at. It really helps to have independent, low coupled systems, said Abel. He mentioned that thinking about the desired design, constantly while coding, really helps:
The Bounded Context concept (from Domain Driven Design) is a great guide to thinking how things can start to be separated and operate independently. I also have a rule that if several services have to be shipped together, we’ve probably built ourselves something too coupled to test, ship and monitor in the way we do.
Getting our products and features released as soon as we can allows us to learn as we go, Abel said. “We can often better see and solve issues in the small; learning good patterns before we scale up,” he mentioned.
InfoQ interviewed Dan Abel, a software engineer, consultant, and coach, about applying observability to ship faster.
InfoQ: What purpose do metrics, monitors, and dashboards serve?
Dan Abel: For us at Tes, these allow us to check in on the health of our systems. They give us confidence that things are working as intended and crucially that our users are reaching their goals.
We instrument our applications to gather metrics - information from our Live systems. We then get visible displays of our service health via dashboards. Crucially we can assert on this data using monitors.
We verify our systems by tracking success and failure metrics, and setting expectations on these via monitors to get alerted if user success drops too low, or if errors rise.
For example, we can ask, “Did we fail to render those PDFs?” “Did we serve those downloads okay?”
For me, that’s test automation in production.
InfoQ: What happened when you arrived at a new company who was shipping fast with fewer tests?
Abel: When I arrived at Tes, I found working in this new way both exciting and challenging. It felt weird to not be running integration suites and thoroughly testing every nook before shipping. I was there to learn about new things and be an engineer with service ownership, so: challenge accepted.
I found myself on a team that was building a replacement job application system. The existing system was extremely valuable to the business, so we needed to find new ways to keep releasing and learning.
“Move fast and break things” couldn’t quite apply here. If we wanted to keep shipping, we needed speedy and accurate feedback from our services in production.
So we asked, “What would happen if we applied what we cared about from test automation, using what we knew about production monitoring?”
And of course - we are engineers. Once we cracked that, we found we could do more complex measuring and monitoring.
#aginext.io london #feedback #automation #observability #measurement #resilience #automated testing #aginext.io london 2020 #agile conferences #culture & methods #devops