Take a step ahead in business management with your portable manager- Runo. A seamless and easy set-up CRM app that offers a modern mode of managing outbound sales and tele- calling processes. Including features such as Caller Id, call recording, live team status, real-time performance analytics, and follow-up notifications among many, this sim based app does it all on the go!

Runo

Introduction In developing large-scale systems, it is always essential to think about resilience. The load on an application typically varies over time based on the number of active users or the types of activities they are performing. One of the most common situations you will encounter sooner or later is server overload caused by unanticipated bursts in traffic. It happens because every server has functional limitations. That means the server has limited network and computational resources like CPU and memory, so the server can effectively handle only a certain number of requests. When the number of requests reaches some threshold and continues growing, it increases resource utilization, leading to higher latency and reducing availability. There are many strategies to handle that situation. For instance, you can run several instances of your application and use autoscaling to match the provisioned resources to the users's needs at any time. However, when the amount of traffic is incredibly huge, scaling out may take time, and may be overloaded or fail. I will discuss common strategies to prevent such a situation in this article. servers Causes leading to traffic spikes There may be many reasons leading to the sudden traffic spikes. Let's consider some of the common. An application can experience sudden spikes in traffic due to events like breaking news, product launches, or promotional campaigns. If the servers are not prepared to handle this surge of traffic, they can quickly become overloaded. Also, when the traffic to the application is dropped temporarily for some reason, the application scales down. Then, when the traffic returns, the application can't scale out fast, leading to server overload and even failure. Another common reason is that malicious bots, or malware, can flood a server with requests, effectively overwhelming its resources. It is known as a distributed denial-of-service (DDoS) attack. Strategies to prevent service overload There are two main strategies to prevent server overload: Throttling, Load shedding. Throttling controls the consumption of resources used by an instance of an application, an individual user, or an entire service. For example, a server experiencing high demand may start throttling requests, slowing them down, or rejecting them until the load subsides. It allows the system to handle the incoming traffic without crashing or becoming unresponsive. One common technique for throttling is rate limiting, which defines the maximum number of requests a user, a client, or an entire group can make within a specific time frame, ensuring no single client or user can monopolize system resources. It is a proactive measure that aims to prevent the system from reaching its capacity in the first place. For instance, a rate limiter may allow 100 requests from a given IP address per minute. Exceeding this limit could result in the user being temporarily blocked or having their requests queued until they are within the allowable rate. Load shedding is a more drastic technique. It involves intentionally dropping requests to prevent a server from becoming overloaded. It is only done as a last resort when other measures, such as rate limiting, have proven insufficient. By shedding requests from one application instance, the load can be redistributed to other application instances in the cluster, preventing any single instance from reaching its limits. An example of rate-limiting Several algorithms can be used to implement rate limiters. Here, let's consider a basic implementation of a rate limiter using a token bucket algorithm, where tokens are added to the bucket at a fixed rate. The request is allowed if a token is available when a request is made. Otherwise, it is denied. This implementation can be applied to throttling requests from particular users, IP addresses, API keys, or other groups of users. main.go package main

import (
	"fmt"
	"log"
	"net/http"
	"sync"
	"time"
)

type bucket struct {
	remainingTokens int
	lastRefillTime  time.Time
}

type RateLimiter struct {
	maxTokens      int
	refillInterval time.Duration
	buckets        map[string]*bucket
	mu             sync.Mutex
}

func NewRateLimiter(rate int, perInterval time.Duration) *RateLimiter {
	return &RateLimiter{
		maxTokens:      rate,
		refillInterval: perInterval,
		buckets:        make(map[string]*bucket),
	}
}

func (rl *RateLimiter) IsLimitReached(id string) bool {
	rl.mu.Lock()
	defer rl.mu.Unlock()

	b, ok := rl.buckets[id]

	// If the bucket doesn't exist, it is the first request for this client.
	// Create a new bucket and allow the request.
	if !ok {
		rl.buckets[id] = &bucket{
			remainingTokens: rl.maxTokens - 1,
			lastRefillTime:  time.Now(),
		}
		return false
	}

	// Calculate the number of tokens to add to the bucket since the last
	// request.
	refillInterval := int(time.Since(b.lastRefillTime) / rl.refillInterval)
	tokensAdded := rl.maxTokens * refillInterval
	currentTokens := b.remainingTokens + tokensAdded

	// There is no tokens to serve the request for this client.
	// Reject the request.
	if currentTokens < 1 {
		return true
	}

	if currentTokens > rl.maxTokens {
		// If the number of current tokens is greater than the maximum allowed,
		// then reset the bucket and decrease the number of tokens by 1.
		b.lastRefillTime = time.Now()
		b.remainingTokens = rl.maxTokens - 1
	} else {
		// Otherwise, update the bucket and decrease the number of tokens by 1.
		deltaTokens := currentTokens - b.remainingTokens
		deltaRefills := deltaTokens / rl.maxTokens
		deltaTime := time.Duration(deltaRefills) * rl.refillInterval
		b.lastRefillTime = b.lastRefillTime.Add(deltaTime)
		b.remainingTokens = currentTokens - 1
	}

	// Allow the request.
	return false
}

type Handler struct {
	rl *RateLimiter
}

func NewHandler(rl *RateLimiter) *Handler {
	return &Handler{rl: rl}
}

func (h *Handler) Handler(w http.ResponseWriter, r *http.Request) {
	// Here should be the logic to get the client ID from the request 
	// (it could be a user ID, an IP address, an API key, etc.)
	clientID := "some-client-id"
	if h.rl.IsLimitReached(clientID) {
		w.WriteHeader(http.StatusTooManyRequests)
		fmt.Fprint(w, http.StatusText(http.StatusTooManyRequests))
		return
	}

	w.WriteHeader(http.StatusOK)
	fmt.Fprint(w, http.StatusText(http.StatusOK))
}

func main() {
	// We allow 1000 requests per second per client to our service.
	rl := NewRateLimiter(1000, 1*time.Second)
	h := NewHandler(rl)
	http.HandleFunc("/", h.Handler)
	log.Fatal(http.ListenAndServe(":8080", nil))
} Let's run our example using Docker Compose with configured for a container. Also, we will use , a benchmarking tool, to check how our application works on different loads. We will use the following and : resource constraints bombardier Dockerfile docker-compose.yml Dockerfile FROM golang:1.21 AS build-stage
WORKDIR /code
COPY main.go ./
RUN CGO_ENABLED=0 GOOS=linux go build -o /service main.go
FROM gcr.io/distroless/base AS build-release-stage
WORKDIR /
COPY --from=build-stage /service /service
EXPOSE 8080
ENTRYPOINT ["/service"] docker-compose.yml services:
  rate_limiting:
    build: .
    ports:
      - "8080:8080"
    deploy:
      resources:
        limits:
          cpus: '.20'
          memory: 100M
        reservations:
          cpus: '0.10'
          memory: 50M Let's run our application using the following command: docker compose -f ./cmd/rate_limiting/docker-compose.yml up --build --force-recreate -d You can monitor the container resource usage using the following command: dcocker stats Let's run the bombardier with different settings and check the results in a separate terminal window. First, let's try sending 10000 requests with one concurrent connection. $ bombardier -c 1 -n 10000 http://127.0.0.1:8080/
Bombarding http://127.0.0.1:8080/ with 10000 request(s) using 1 connection(s)
 10000 / 10000 [===============================================================] 100.00% 859/s 11s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec       868.33     833.53    2684.45
  Latency        1.15ms     6.93ms    75.42ms
  HTTP codes:
    1xx - 0, 2xx - 10000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   151.93KB/s From the results, you can see that the request rate on average is less than 1000 requests per second, which is the maximum allowed rate, and all requests were processed successfully. Next,  let's try sending 10000 requests with 100 concurrent connections. $ bombardier -c 100 -n 10000 http://127.0.0.1:8080/
Bombarding http://127.0.0.1:8080/ with 10000 request(s) using 100 connection(s)
 10000 / 10000 [===============================================================] 100.00% 3320/s 3s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      3395.87    6984.32   32322.59
  Latency       28.02ms    37.61ms   196.95ms
  HTTP codes:
    1xx - 0, 2xx - 3000, 3xx - 0, 4xx - 7000, 5xx - 0
    others - 0
  Throughput:   675.35KB/s You can see that the server started to return HTTP 429 status code, which means the server is overloaded due to many requests. Clean up your environment using the following command after all tests are done: docker compose -f ./cmd/rate_limiting/docker-compose.yml down --remove-orphans --timeout 1 --volumes An example of load-shedding Depending on your particular case, you can use different approaches to load shedding: Dropping random requests when the system becomes overloaded, Using a load balancer to distribute the load evenly, Monitoring server load continuously and dropping or rejecting requests when a certain load level is reached, Monitoring system metrics like CPU utilization, network I/O, or memory usage and dropping requests when these metrics reach certain thresholds, Set up priority levels for requests and start refusing low-priority requests when the system is under load, Etc. Load shedding can be implemented at various levels, including load balancers, servers, and software libraries. It requires careful planning and implementation, as poorly implemented load shedding can result in important requests being dropped, causing a negative impact on user experience or system functionality. Let's implement a simple load-shedding mechanism by detecting request overload conditions and responding with an HTTP 503 status code. main .go package main

import (
	"context"
	"fmt"
	"log"
	"net/http"
	"sync/atomic"
	"time"
)

type LoadShedder struct {
	isOverloaded atomic.Bool
}

func NewLoadShedder(ctx context.Context, checkInterval, overloadFactor time.Duration) *LoadShedder {
	ls := LoadShedder{}

	go ls.runOverloadDetector(ctx, checkInterval, overloadFactor)

	return &ls
}

func (ls *LoadShedder) runOverloadDetector(ctx context.Context, checkInterval, overloadFactor time.Duration) {
	ticker := time.NewTicker(checkInterval)
	defer ticker.Stop()

	// Start with a fresh start time.
	startTime := time.Now()
	for {
		select {
		case <-ctx.Done():
			return
		case <-ticker.C:
			// Check how long it took to process the last batch of requests.
			elapsed := time.Since(startTime)
			if elapsed > overloadFactor {
				// If it took longer than the overload factor, we're overloaded.
				ls.isOverloaded.Store(true)
			} else {
				// Otherwise, we're not overloaded.
				ls.isOverloaded.Store(false)
			}
			// Reset the start time.
			startTime = time.Now()
		}
	}
}

func (ls *LoadShedder) IsOverloaded() bool {
	return ls.isOverloaded.Load()
}

type Handler struct {
	ls *LoadShedder
}

func NewHandler(ls *LoadShedder) *Handler {
	return &Handler{ls: ls}
}

func (h *Handler) Handler(w http.ResponseWriter, r *http.Request) {
	if h.ls.IsOverloaded() {
		w.WriteHeader(http.StatusServiceUnavailable)
		fmt.Fprint(w, http.StatusText(http.StatusServiceUnavailable))
		return
	}

	w.WriteHeader(http.StatusOK)
	fmt.Fprint(w, http.StatusText(http.StatusOK))
}

func main() {
	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	// The load shedder will check every 100ms if the last batch of requests
	// took longer than 200ms.
	ls := NewLoadShedder(ctx, 100*time.Millisecond, 200*time.Millisecond)

	h := NewHandler(ls)
	http.HandleFunc("/", h.Handler)

	log.Fatal(http.ListenAndServe(":8080", nil))
} We define the struct to run the load detector used in our request handler to check if we should return the HTTP 503 status code or process the request. The struct has an atomic flag indicating if the system is overloaded. We use atomic boolean value to make it thread-safe. We also have the method that returns the current value of the flag. In the function, we create a new and run the overload detector in a goroutine that checks according to the specified interval if the system is overloaded based on the overload factor. We check how much time has passed since the last check. If it is higher than the overload factor, the system is overloaded. That means that our request handler used resources for too long, and we need more capacity to handle the requests. LoadShedder LoadShedder IsOverloaded NewLoadShedder LoadShedder Let's run our example using. We will use the following and : Dockerfile docker-compose.yml Dockerfile FROM golang:1.21 AS build-stage
WORKDIR /code
COPY main.go ./
RUN CGO_ENABLED=0 GOOS=linux go build -o /service main.go
FROM gcr.io/distroless/base AS build-release-stage
WORKDIR /
COPY --from=build-stage /service /service
EXPOSE 8080
ENTRYPOINT ["/service"] docker-compose.yml services:
  load_shedding:
    build: .
    ports:
      - "8080:8080"
    deploy:
      resources:
        limits:
          cpus: '.20'
          memory: 100M
        reservations:
          cpus: '0.10'
          memory: 50M Let's run our application using the following command: docker compose -f ./cmd/load_shedding/docker-compose.yml up --build --force-recreate -d You can monitor the container resource usage using the following command: dcocker stats Let's run the bombardier with different settings and check the results in a separate terminal window. First, let's try sending 10000 requests with 10 concurrent connections. $ bombardier -c 10 -n 10000 http://127.0.0.1:8080/
Bombarding http://127.0.0.1:8080/ with 10000 request(s) using 10 connection(s)
 10000 / 10000 [===============================================================] 100.00% 1346/s 7s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      1389.49    1582.00    6284.42
  Latency        7.24ms    22.41ms    98.43ms
  HTTP codes:
    1xx - 0, 2xx - 10000, 3xx - 0, 4xx - 0, 5xx - 0
    others - 0
  Throughput:   242.78KB/s The results show that the maximum latency is less than 100 ms, and all requests were processed successfully. Next, let's try sending 10000 requests with 1000 concurrent connections. $ bombardier -c 1000 -n 10000 http://127.0.0.1:8080/
Bombarding http://127.0.0.1:8080/ with 10000 request(s) using 1000 connection(s)
 10000 / 10000 [===============================================================] 100.00% 3791/s 2s
Done!
Statistics        Avg      Stdev        Max
  Reqs/sec      4242.28   11985.30   58592.64
  Latency      211.67ms   210.89ms      1.54s
  HTTP codes:
    1xx - 0, 2xx - 8823, 3xx - 0, 4xx - 0, 5xx - 1177
    others - 0
  Throughput:   696.96KB/s You can see that the server started to return HTTP 503 status code, which means the server is overloaded due to many requests, and you can see the maximum latency is more than 1 second. Clean up your environment using the following command after all tests are done: docker compose -f ./cmd/load_shedding/docker-compose.yml down --remove-orphans --timeout 1 --volumes Conclusion In this article, we discussed the causes leading to traffic spikes and strategies to prevent server overload. We also implemented a simple rate limiter and load shedder to demonstrate how they work. You can find all the code from the article here . https://github.com/ivanlemeshev/resilience For the production environment, you can use ready-to-use rate limiters like or . https://pkg.go.dev/golang.org/x/time/rate https://github.com/uber-go/ratelimit

How To Prevent Server Overload In Go

A Journey to the Center of the Earth by Jules Verne, is part of the HackerNoon Books Series. You can jump to any chapter in this book . WE CONTINUE OUR DESCENT here CHAPTER XV - WE CONTINUE OUR DESCENT At eight o'clock the next morning, a faint kind of dawn of day awoke us. The thousand and one prisms of the lava collected the light as it passed and brought it to us like a shower of sparks. We were able with ease to see objects around us. "Well, Harry, my boy," cried the delighted Professor, rubbing his hands together, "what say you now? Did you ever pass a more tranquil night in our house in the Konigstrasse? No deafening sounds of cart wheels, no cries of hawkers, no bad language from boatmen or watermen!" "Well, Uncle, we are quite at the bottom of this well—but to me there is something terrible in this calm." "Why," said the Professor hotly, "one would say you were already beginning to be afraid. How will you get on presently? Do you know, that as yet, we have not penetrated one inch into the bowels of the earth." "What can you mean, sir?" was my bewildered and astonished reply. "I mean to say that we have only just reached the soil of the island itself. This long vertical tube, which ends at the bottom of the crater of Sneffels, ceases here just about on a level with the sea." "Are you sure, sir?" "Quite sure. Consult the barometer." It was quite true that the mercury, after rising gradually in the instrument, as long as our descent was taking place, had stopped precisely at twenty-nine degrees. "You perceive," said the Professor, "we have as yet only to endure the pressure of air. I am curious to replace the barometer by the manometer." The barometer, in fact, was about to become useless—as soon as the weight of the air was greater than what was calculated as above the level of the ocean. "But," said I, "is it not very much to be feared that this ever-increasing pressure may not in the end turn out very painful and inconvenient?" "No," said he. "We shall descend very slowly, and our lungs will be gradually accustomed to breathe compressed air. It is well known that aeronauts have gone so high as to be nearly without air at all—why, then, should we not accustom ourselves to breathe when we have, say, a little too much of it? For myself, I am certain I shall prefer it. Let us not lose a moment. Where is the packet which preceded us in our descent?" I smilingly pointed it out to my uncle. Hans had not seen it, and believed it caught somewhere above us: "Huppe" as he phrased it. "Now," said my uncle, "let us breakfast, and break fast like people who have a long day's work before them." Biscuit and dried meat, washed down by some mouthfuls of water flavored with Schiedam, was the material of our luxurious meal. As soon as it was finished, my uncle took from his pocket a notebook destined to be filled by memoranda of our travels. He had already placed his instruments in order, and this is what he wrote: Monday, June 29th Chronometer, 8h. 17m. morning. Barometer, 29.6 inches. Thermometer, 6 degrees [43 degrees Fahr.] Direction, E.S.E. This last observation referred to the obscure gallery, and was indicated to us by the compass. "Now, Harry," cried the Professor, in an enthusiastic tone of voice, "we are truly about to take our first step into the Interior of the Earth; never before visited by man since the first creation of the world. You may consider, therefore, that at this precise moment our travels really commence." As my uncle made this remark, he took in one hand the Ruhmkorff coil apparatus, which hung round his neck, and with the other he put the electric current into communication with the worm of the lantern. And a bright light at once illumined that dark and gloomy tunnel! The effect was magical! Hans, who carried the second apparatus, had it also put into operation. This ingenious application of electricity to practical purposes enabled us to move along by the light of an artificial day, amid even the flow of the most inflammable and combustible gases. "Forward!" cried my uncle. Each took up his burden. Hans went first, my uncle followed, and I going third, we entered the somber gallery! Just as we were about to engulf ourselves in this dismal passage, I lifted up my head, and through the tubelike shaft saw that Iceland sky I was never to see again! Was it the last I should ever see of any sky? The stream of lava flowing from the bowels of the earth in 1219 had forced itself a passage through the tunnel. It lined the whole of the inside with its thick and brilliant coating. The electric light added very greatly to the brilliancy of the effect. The great difficulty of our journey now began. How were we to prevent ourselves from slipping down the steeply inclined plane? Happily some cracks, abrasures of the soil, and other irregularities, served the place of steps; and we descended slowly; allowing our heavy luggage to slip on before, at the end of a long cord. But that which served as steps under our feet became in other places stalactites. The lava, very porous in certain places, took the form of little round blisters. Crystals of opaque quartz, adorned with limpid drops of natural glass suspended to the roof like lusters, seemed to take fire as we passed beneath them. One would have fancied that the genii of romance were illuminating their underground palaces to receive the sons of men. "Magnificent, glorious!" I cried in a moment of involuntary enthusiasm, "What a spectacle, Uncle! Do you not admire these variegated shades of lava, which run through a whole series of colors, from reddish brown to pale yellow—by the most insensible degrees? And these crystals, they appear like luminous globes." "You are beginning to see the charms of travel, Master Harry," cried my uncle. "Wait a bit, until we advance farther. What we have as yet discovered is nothing—onwards, my boy, onwards!" It would have been a far more correct and appropriate expression, had he said, "let us slide," for we were going down an inclined plane with perfect ease. The compass indicated that we were moving in a southeasterly direction. The flow of lava had never turned to the right or the left. It had the inflexibility of a straight line. Nevertheless, to my surprise, we found no perceptible increase in heat. This proved the theories of Humphry Davy to be founded on truth, and more than once I found myself examining the thermometer in silent astonishment. Two hours after our departure it only marked fifty-four degrees Fahrenheit. I had every reason to believe from this that our descent was far more horizontal than vertical. As for discovering the exact depth to which we had attained, nothing could be easier. The Professor as he advanced measured the angles of deviation and inclination; but he kept the result of his observations to himself. About eight o'clock in the evening, my uncle gave the signal for halting. Hans seated himself on the ground. The lamps were hung to fissures in the lava rock. We were now in a large cavern where air was not wanting. On the contrary, it abounded. What could be the cause of this—to what atmospheric agitation could be ascribed this draught? But this was a question which I did not care to discuss just then. Fatigue and hunger made me incapable of reasoning. An unceasing march of seven hours had not been kept up without great exhaustion. I was really and truly worn out; and delighted enough I was to hear the word Halt. Hans laid out some provisions on a lump of lava, and we each supped with keen relish. One thing, however, caused us great uneasiness—our water reserve was already half exhausted. My uncle had full confidence in finding subterranean resources, but hitherto we had completely failed in so doing. I could not help calling my uncle's attention to the circumstance. "And you are surprised at this total absence of springs?" he said. "Doubtless—I am very uneasy on the point. We have certainly not enough water to last us five days." "Be quite easy on that matter," continued my uncle. "I answer for it we shall find plenty of water—in fact, far more than we shall want." "But when?" "When we once get through this crust of lava. How can you expect springs to force their way through these solid stone walls?" "But what is there to prove that this concrete mass of lava does not extend to the centre of the earth? I don't think we have as yet done much in a vertical way." "What puts that into your head, my boy?" asked my uncle mildly. "Well, it appears to me that if we had descended very far below the level of the sea—we should find it rather hotter than we have." "According to your system," said my uncle; "but what does the thermometer say?" "Scarcely fifteen degrees by Reaumur, which is only an increase of nine since our departure." "Well, and what conclusion does that bring you to?" inquired the Professor. "The deduction I draw from this is very simple. According to the most exact observations, the augmentation of the temperature of the interior of the earth is one degree for every hundred feet. But certain local causes may considerably modify this figure. Thus at Yakoust in Siberia, it has been remarked that the heat increases a degree every thirty-six feet. The difference evidently depends on the conductibility of certain rocks. In the neighborhood of an extinct volcano, it has been remarked that the elevation of temperature was only one degree in every five-and-twenty feet. Let us, then, go upon this calculation—which is the most favorable—and calculate." "Calculate away, my boy." "Nothing easier," said I, pulling out my notebook and pencil. "Nine times one hundred and twenty-five feet make a depth of eleven hundred and twenty-five feet." "Archimedes could not have spoken more geometrically." "Well?" "Well, according to my observations, we are at least ten thousand feet below the level of the sea." "Can it be possible?" "Either my calculation is correct, or there is no truth in figures." The calculations of the Professor were perfectly correct. We were already six thousand feet deeper down in the bowels of the earth than anyone had ever been before. The lowest known depth to which man had hitherto penetrated was in the mines of Kitzbuhel, in the Tirol, and those of Wurttemberg. The temperature, which should have been eighty-one, was in this place only fifteen. This was a matter for serious consideration. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Jules Verne (2006). A Journey to the Center of the Earth. Urbana, Illinois: Project Gutenberg. Retrieved October 2022 https://www.gutenberg.org/files/18857/18857-h/18857-h.htm This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

WE CONTINUE OUR DESCENT

In this article, we'll explore common pitfalls and potential solutions when working with (using ts-node) in Development Pipelines. This piece is particularly valuable for developers encountering problems during the deployment process, often characterized by obscure error messages and puzzling behavior. We'll take a practical, step-by-step approach, investigating these issues, delving into their root causes, and outlining strategies for fixing them. TypeScript Azure Serverless Whether you're a seasoned developer, DevOps engineer, or a curious beginner eager to learn more about TypeScript and Azure DevOps, this comprehensive guide will serve as a valuable tool in navigating the intricacies of ts-node deployments in Azure pipelines. Problem Working on and building our backend system on different cloud solutions ( , Azure) our team has faced several issues on serverless deployment. Restart GCP Using as a runtime in-memory with the latest TypeScript 5.0.4 and nodejs18, we got errors after successfully building our app using dev.azure.com pipelines (Image 1). ts-node ts-js compiler The errors during app startup: 2023-05-25T10:52:24.326355260Z    _____
2023-05-25T10:52:24.326400861Z   /  _  \ __________ _________   ____
2023-05-25T10:52:24.326406761Z  /  /_\  \\___   /  |  \_  __ \_/ __ \
2023-05-25T10:52:24.326410361Z /    |    \/    /|  |  /|  | \/\  ___/
2023-05-25T10:52:24.326413761Z \____|__  /_____ \____/ |__|    \___  >
2023-05-25T10:52:24.326417661Z         \/      \/                  \/
2023-05-25T10:52:24.326420961Z A P P   S E R V I C E   O N   L I N U X
2023-05-25T10:52:24.326424361Z
2023-05-25T10:52:24.326427461Z Documentation: http://aka.ms/webapp-linux
2023-05-25T10:52:24.326430661Z NodeJS quickstart: https://aka.ms/node-qs
2023-05-25T10:52:24.326433761Z NodeJS Version : v18.16.0
2023-05-25T10:52:24.326436961Z Note: Any data outside '/home' is not persisted
2023-05-25T10:52:24.326440161Z
2023-05-25T10:52:26.504451955Z Starting OpenBSD Secure Shell server: sshd.
2023-05-25T10:52:26.807519399Z Starting periodic command scheduler: cron.
2023-05-25T10:52:26.863716274Z Cound not find build manifest file at '/home/site/wwwroot/oryx-manifest.toml'
2023-05-25T10:52:26.866811884Z Could not find operation ID in manifest. Generating an operation id...
2023-05-25T10:52:26.868247288Z Build Operation ID: 796ee1ba-542e-43f1-9f6c-1e7a5e2e9815
2023-05-25T10:52:27.139574733Z Environment Variables for Application Insight's IPA Codeless Configuration exists..
2023-05-25T10:52:27.156085084Z Writing output script to '/opt/startup/startup.sh'
2023-05-25T10:52:27.229878114Z Running #!/bin/sh
2023-05-25T10:52:27.229938514Z
2023-05-25T10:52:27.229945514Z # Enter the source directory to make sure the script runs where the user expects
2023-05-25T10:52:27.229950214Z cd "/home/site/wwwroot"
2023-05-25T10:52:27.229954114Z
2023-05-25T10:52:27.229957814Z export NODE_PATH=/usr/local/lib/node_modules:$NODE_PATH
2023-05-25T10:52:27.229979514Z if [ -z "$PORT" ]; then
2023-05-25T10:52:27.230057715Z 		export PORT=8080
2023-05-25T10:52:27.230063815Z fi
2023-05-25T10:52:27.230067915Z
2023-05-25T10:52:27.246143265Z PATH="$PATH:/home/site/wwwroot" yarn start
2023-05-25T10:52:30.491250324Z yarn run v1.17.3
2023-05-25T10:52:30.896237571Z $ ts-node src/app.ts
2023-05-25T10:52:31.521499168Z node:internal/modules/cjs/loader:1078
2023-05-25T10:52:31.577313557Z   throw err;
2023-05-25T10:52:31.577384758Z   ^
2023-05-25T10:52:31.577391958Z
2023-05-25T10:52:31.577396558Z Error: Cannot find module './util'
2023-05-25T10:52:31.577400858Z Require stack:
2023-05-25T10:52:31.577404958Z - /home/site/wwwroot/node_modules/.bin/ts-node
2023-05-25T10:52:31.577484858Z     at Module._resolveFilename (node:internal/modules/cjs/loader:1075:15)
2023-05-25T10:52:31.577494058Z     at Module._load (node:internal/modules/cjs/loader:920:27)
2023-05-25T10:52:31.577498458Z     at Module.require (node:internal/modules/cjs/loader:1141:19)
2023-05-25T10:52:31.577502658Z     at require (node:internal/modules/cjs/helpers:110:18)
2023-05-25T10:52:31.577506858Z     at Object.<anonymous> (/home/site/wwwroot/node_modules/.bin/ts-node:9:16)
2023-05-25T10:52:31.577511558Z     at Module._compile (node:internal/modules/cjs/loader:1254:14)
2023-05-25T10:52:31.577551858Z     at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
2023-05-25T10:52:31.577557158Z     at Module.load (node:internal/modules/cjs/loader:1117:32)
2023-05-25T10:52:31.577561358Z     at Module._load (node:internal/modules/cjs/loader:958:12)
2023-05-25T10:52:31.577565458Z     at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) {
2023-05-25T10:52:31.577569658Z   code: 'MODULE_NOT_FOUND',
2023-05-25T10:52:31.577573658Z   requireStack: [ '/home/site/wwwroot/node_modules/.bin/ts-node' ]
2023-05-25T10:52:31.577577758Z }
2023-05-25T10:52:31.577586558Z
2023-05-25T10:52:31.577591058Z Node.js v18.16.0
2023-05-25T10:52:31.684203528Z error Command failed with exit code 1. The key points of these logs are: Error: Cannot find module './util' /home/site/wwwroot/node_modules/.bin/ts-node requireStack: [ '/home/site/wwwroot/node_modules/.bin/ts-node' ] error Command failed with exit code 1. Spending hours of googling and searching for similar problems on Stack Overflow, we cannot define the nature of the issue. Trying different pipeline setups, and switching from Linux based web app to Windows does not help. The same code works fine in the case of serverless Google Cloud, but for some reason does not work on serverless Azure. Finally, we got a solution: We switch to a basic compiler and everything worked fine. “ts-node” “tsc“ In this article, I will explain some details of switching your existing project, that uses to a native compiler. ts-node tsc Tiny ts-node project First, we need a basic project that has only one file and ts-node on it (Image 2). The folder contains our app.ts file: src import * as http from 'http';

const server = http.createServer((req, res) => {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain');
    res.end('Hello Hackernoon. We are using ts on Azure!\n');
});

server.listen(8080, '0.0.0.0', () => {
    console.log('Server running at http://0.0.0.0:8080/');
}); In we have added folder and because compiling from to will be inside the Azure pipeline process. .gitignore dist node_modules ts js The content of package.json: {
  "name": "ts-nodejs",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "start": "ts-node src/app.ts"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "ts-node": "^10.9.1",
    "typescript": "^5.0.4"
  },
  "devDependencies": {
    "@types/node": "^20.2.3"
  }
} We have installed only ts-node and typescript packages. First, we need to modify the start command and create a new command and add it here: {
  "name": "tsc-nodejs",
  "version": "1.0.0",
  "description": "",
  "scripts": {
    "start": "node dist/app.js",
    "build": "tsc"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "ts-node": "^10.9.1",
    "typescript": "^5.0.4"
  },
  "devDependencies": {
    "@types/node": "^20.2.3"
  }
} All project pre-compiled files will be stored in the folder, which will execute our entry point of the app (app.js). the command executes or compiler. It gets settings from file. dist nodejs Build tsc tsconfig.json Our settings will be: {
  "compilerOptions": {
    "target": "ES2019",
    "module": "commonjs",
    "esModuleInterop": true,
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "noFallthroughCasesInSwitch": true,
    "noImplicitAny": false,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "strictBindCallApply": true,
    "strictFunctionTypes": true,
    "strictNullChecks": true,
    "strictPropertyInitialization": true,
    "removeComments": true,
    "strict": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "dist",
    "baseUrl": "./src",
    "rootDir": "src",
    "paths": {
      "@extensions/*": ["handlers/extensions/*"],
      "@services/*": ["services/*"],
      "@docs/*": ["docs/*"],
      "@server/*": ["server/*"],
      "@handlers/*": ["handlers/*"],
      "@app/*": ["*"],
    },
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "typeRoots": [
      "./types",
      "./node_modules/@types"
    ],
    "allowSyntheticDefaultImports": true,
    "lib": ["es5", "es6", "dom"],
    "moduleResolution": "node",
  },
  "include": [
    "**/*"
  ],
  "exclude": [
    "dist",
    "node_modules"
  ]
} The most important parts of the tsconfig.json: "noEmit": false,
 "include": [
    "**/*"
  ],
"outDir": "dist",
"baseUrl": "./src",
"rootDir": "src", Be sure, that is false (by default is false), is the name of the folder, where will save precompiled files, and is , where your project is (don’t save project files outside folder, because will ignore them). noEmit outDir tsc baseUrl rootDir src src tsc In this example, I also have added in case you have it on an existing project, but this tiny project does not use its allies, so you can ignore them. If you use allies on your project, please change them inside from: paths package.json "_moduleAliases": {
    "@extensions": "src/handlers/extensions",
    "@services": "src/services",
    "@docs": "src/docs",
    "@server": "src/server",
    "@handlers": "src/handlers",
    "@app": "src"
  } to this: "_moduleAliases": {
    "@extensions": "dist/handlers/extensions",
    "@services": "dist/services",
    "@docs": "dist/docs",
    "@server": "dist/server",
    "@handlers": "dist/handlers",
    "@app": "dist"
  } Finally, you need to change basic config from: azure-pipelines.yaml # Node.js Express Web App to Linux on Azure
# Build a Node.js Express app and deploy it to Azure as a Linux web app.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

trigger:
- master

variables:

  # Azure Resource Manager connection created during pipeline creation
  azureSubscription: '<Your sub>'

  # Web app name
  webAppName: '<Your webAppName>'

  # Environment name
  environmentName: 'Your webAppName>'

  # Agent VM image name
  vmImageName: 'ubuntu-latest'

stages:
- stage: Build
  displayName: Build stage
  jobs:
  - job: Build
    displayName: Build
    pool:
      vmImage: $(vmImageName)

    steps:
    - task: NodeTool@0
      inputs:
        versionSpec: '18.x'
      displayName: 'Install Node.js'

    - script: |
        npm install yarn
        yarn
      displayName: 'npm install, build and test'

    - task: ArchiveFiles@2
      displayName: 'Archive files'
      inputs:
        rootFolderOrFile: '$(System.DefaultWorkingDirectory)'
        includeRootFolder: false
        archiveType: zip
        archiveFile: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
        replaceExistingArchive: true

    - upload: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
      artifact: drop

- stage: Deploy
  displayName: Deploy stage
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: Deploy
    displayName: Deploy
    environment: $(environmentName)
    pool:
      vmImage: $(vmImageName)
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            displayName: 'Azure Web App Deploy: Your webAppName>'
            inputs:
              azureSubscription: $(azureSubscription)
              appType: webAppLinux
              appName: $(webAppName)
              runtimeStack: 'NODE|18-lts'
              package: $(Pipeline.Workspace)/drop/$(Build.BuildId).zip
              startUpCommand: 'yarn start' to this: # Node.js Express Web App to Linux on Azure
# Build a Node.js Express app and deploy it to Azure as a Linux web app.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

trigger:
- master

variables:

  # Azure Resource Manager connection created during pipeline creation
  azureSubscription: 'Your sub'

  # Web app name
  webAppName: 'Your webAppName>'

  # Environment name
  environmentName: 'Your webAppName>'

  # Agent VM image name
  vmImageName: 'ubuntu-latest'

stages:
- stage: Build
  displayName: Build stage
  jobs:
  - job: Build
    displayName: Build
    pool:
      vmImage: $(vmImageName)

    steps:
    - task: NodeTool@0
      inputs:
        versionSpec: '18.x'
      displayName: 'Install Node.js'

    - script: |
        npm install yarn
        yarn
        yarn build
      displayName: 'npm install, build and test'

    - task: ArchiveFiles@2
      displayName: 'Archive files'
      inputs:
        rootFolderOrFile: '$(System.DefaultWorkingDirectory)'
        includeRootFolder: false
        archiveType: zip
        archiveFile: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
        replaceExistingArchive: true

    - upload: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
      artifact: drop

- stage: Deploy
  displayName: Deploy stage
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: Deploy
    displayName: Deploy
    environment: $(environmentName)
    pool:
      vmImage: $(vmImageName)
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            displayName: 'Azure Web App Deploy: Your webAppName>'
            inputs:
              azureSubscription: $(azureSubscription)
              appType: webAppLinux
              appName: $(webAppName)
              runtimeStack: 'NODE|18-lts'
              package: $(Pipeline.Workspace)/drop/$(Build.BuildId).zip
              startUpCommand: 'yarn start' Finally, and see what will happen! git push Conclusion Hope this article will save a lot of time during debugging process in case of using with . It's clear that the complexities of TypeScript deployments within Azure DevOps pipelines can present unique challenges. However, by taking a systematic approach and learning to understand the underpinnings of ts-node and Azure pipelines, we can effectively troubleshoot and resolve these obstacles. ts-node Azure Node.js Serverless Apps In this article, we dove into the most common issues developers encounter, broke down the intricacies of these problems, and provided step-by-step solutions. Remember, it's not about avoiding problems altogether – it's about developing the ability to diagnose, troubleshoot, and solve them effectively when they inevitably arise. Moving forward, take this knowledge and apply it to your DevOps processes. Not only will you increase your productivity, but you'll also be contributing to a smoother, more efficient pipeline for your entire team. There's always more to learn in this ever-evolving field, and this guide is just one step towards mastering Azure DevOps with TypeScript. Stay curious, keep learning, and happy coding!

Resolving Deployment Issues with Ts-node and Azure Development Pipelines

Hello, software adventurers! Today, we'll be embarking on a new journey — a journey where you'll learn how to set up a pipeline to deploy serverless Node.js applications on Azure. If you're new to software development, fear not! This article is specially tailored to provide you with a gentle, yet comprehensive, introduction to this exciting area of . cloud computing With the rise of cloud computing, the concept of serverless computing has become more prominent. The term "serverless" doesn't mean there are no servers, but rather that you don't have to manage them. Essentially, it enables you to focus more on writing code and less on infrastructure management. is a top-tier cloud services provider that offers a robust platform for serverless applications. In this guide, we'll be using Azure Functions, a serverless computing service that lets you run event-triggered code without having to provision or manage infrastructure. Microsoft Azure Article Content Setting Up Azure Account Creating A Web App Resource Creating Node.js Application Setting Up Azure DevOps Project Configuring Azure Pipeline Deploying Your Serverless Application Let's dive in and start exploring these sections one by one. Setting Up Azure Account Before we can deploy anything, we first need to create an Azure account. If you haven't done this before, follow these steps: Visit the Azure portal at . https://portal.azure.com Click on . "Create a free account" Fill in your details and follow the prompts. After all, you'll get in Azure credits and free access to popular services for 12 months. $200 Creating A Web App Resource The comprehensive procedure was covered in . Our goal is to establish a fully operational web application server, serving as a bridge between our deployment pipeline on dev.azure.com and the previously created web application. Consequently, every change in the branch will trigger an automatic deployment of our web application. another article Creating a Node.js Application To create a "Hello World" application in Node.js, follow these steps: Install Node.js If you don't have Node.js installed on your computer, you can download it from . , the latest LTS version of Node.js is 18. Follow the instructions on the website to install it. https://nodejs.org/ Setup Your Project Create a new directory on your computer where you want your project to reside. Open a terminal or command prompt, navigate to your newly created directory, and initiate a new Node.js project by typing the following command: npm init -y The command creates a new file in your directory with default values. The file is used to manage the dependencies of your Node.js project. npm init -y package.json package.json Create a New JavaScript File In the same directory, create a new JavaScript file. You can name it anything you like, but for this example, let's call it . app.js Write the "Hello World" Code Open file in your preferred text editor and enter the following code: app.js const http = require('http');

const server = http.createServer((req, res) => {
    res.statusCode = 200;
    res.setHeader('Content-Type', 'text/plain');
    res.end('Hello World\n');
});

server.listen(8080, '0.0.0.0', () => {
    console.log('Server running at http://0.0.0.0:8080/');
}); Also, you need to change the file to run in on Azure: package.json {
  "name": "hackernoon",
  "version": "1.0.0",
  "description": "",
  "main": "app.js",
  "scripts": {
    "start": "node app.js"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
} Setting Up Azure DevOps Project After creating your Azure account and Node.js application, the next step is to create an Azure DevOps project: Go to the Azure DevOps portal at . https://dev.azure.com Log in with your Azure account. Click on and provide a name and description for the project. "New project" Configuring Azure Pipeline To set up your automatic deploy pipeline, you need to store the project code somewhere. We need to upload our project to the private Azure git repo (Image 1). Using you should upload your code to Azure Repos. Some commands that I have used (inside the project folder I have opened cmd.exe and wrote these commands) git git init
git remote add origin https://<your_name>/<Your name>/hackernoon/_git/hackernoon
git add .
git commit -m "initial"
git push --set-upstream origin master After doing this, your code will be on Azure Cloud. Next step, you should click on the button (Image 2). “Pipelines“ Then . Choose (Image 3), then choose Node.js App for Linux (Image 4). “Create Pipeline” “Azure Repos Git“ Then the process will ask you to get access to your subscription plan and after all, you will see your Web App name, which you have created earlier (Image 5). Finally, Azure will create a file for us. We need to change some parameters. yaml # Node.js Express Web App to Linux on Azure
# Build a Node.js Express app and deploy it to Azure as a Linux web app.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/javascript

trigger:
- master

variables:

  # Azure Resource Manager connection created during pipeline creation
  azureSubscription: '<Your sub>'

  # Web app name
  webAppName: '<Your name>'

  # Environment name
  environmentName: 'Your name'

  # Agent VM image name
  vmImageName: 'ubuntu-latest'

stages:
- stage: Build
  displayName: Build stage
  jobs:
  - job: Build
    displayName: Build
    pool:
      vmImage: $(vmImageName)

    steps:
    - task: NodeTool@0
      inputs:
        # change this "versionSpec: '10.x' to versionSpec: '18.x'
      displayName: 'Install Node.js'

    - script: |
        npm install
        # Delete this "npm run build --if-present"
        # Delete this "npm run test --if-present"
      displayName: 'npm install, build and test'

    - task: ArchiveFiles@2
      displayName: 'Archive files'
      inputs:
        rootFolderOrFile: '$(System.DefaultWorkingDirectory)'
        includeRootFolder: false
        archiveType: zip
        archiveFile: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
        replaceExistingArchive: true

    - upload: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
      artifact: drop

- stage: Deploy
  displayName: Deploy stage
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: Deploy
    displayName: Deploy
    environment: $(environmentName)
    pool:
      vmImage: $(vmImageName)
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            displayName: 'Azure Web App Deploy: <Your name>'
            inputs:
              azureSubscription: $(azureSubscription)
              appType: webAppLinux
              appName: $(webAppName)
              runtimeStack: 'NODE|10.10'
              package: $(Pipeline.Workspace)/drop/$(Build.BuildId).zip
              startUpCommand: 'npm run start' Press button. Commit directly to the branch. It will add this new config file to your project. For the first time, you will be asked for permission (Image 6). “Save and run” Deploying Your Serverless Application Finally, we can deploy our serverless application to Azure (Image 7). Once the upload is complete, your serverless Node.js application should be live on Azure (Image 8). And there you have it — you've just set up a pipeline to deploy serverless Node.js applications on Azure! Take a moment to celebrate this accomplishment. Conclusion As we wrap up, it's crucial to understand the value of setting up a deployment pipeline for a Serverless Node.js application on Azure. We have demonstrated how, through the use of Azure Functions, Azure DevOps, and other Azure services, you can automate your deployment process, ensuring smoother, more efficient, and error-free deployments. Incorporating a pipeline significantly reduces the risk of deployment-related issues and enhances the overall quality of the software. It promotes an efficient development practice that encourages frequent code changes while providing instant feedback on the success of these changes. CI/CD This tutorial should serve as a robust foundation, providing the necessary tools and understanding to further explore the potential of Azure and its integration capabilities. It's now time for you to take this knowledge and apply it to your projects, customizing and optimizing as per your unique requirements. At the end of the day, the goal is to automate processes, increase productivity, and deliver high-quality, efficient applications, and hopefully, this guide has brought you one step closer to achieving that. Happy coding!

How to Set Up a Pipeline for Deploying Serverless Node.js on Azure

or UI refers to the visual and interactive elements that users interact with when using a mobile app. It includes layouts, designs, and presentations of different app-related interface components like text fields, buttons, menus, images, and so many other graphical elements that a good app needs. User Interface Attractive UI captivates the users with an enhanced experience while interacting with the app so, it will be important to keep in mind to design the best possible user-friendly interface to allow users to have a seamless experience while accessing the app’s functionalities. Despite attempting to build a well-executed UI for an app, some bugs could still persist to affect the overall app’s performance. Sometimes, UI issues can be challenging to identify and resolve just like trying to untangle a bowl of spaghetti with a pair of chopsticks—just when you think you've got it, another noodle jumps out😁! So, proper expertise is essential for the systematic debugging of an app. This article is for exploring different debugging methods for UI-related issues. 📥Key Aspects Associated with a Good UI Design A good UI design for a well-functioning app needs several key aspects for creating a visually appealing, intuitive, and user-friendly interface. Here, a few of them are demonstrated in the following figure. The primary goal of a well-designed UI is to create an attractive and user-friendly interface that allows users to easily understand and interact with the app's functionalities which involves the thoughtful arrangement of elements, appropriate colour combinations, font sizes and styles, visual cues, and many more. The debugging process can be performed systematically as follows: 📥Understanding Common & Complex UI Issues or the Bugs to Solve ⬇️Common Bugs: Here are the most common UI-related bugs associated with mobile apps. 👉🏿Layout issues: This issue consists of inconsistent or broken layouts, overlapping elements, and misaligned views that can disrupt the user experience. Here is a code example of the issue and its solution. Misaligned Views: Code Example: <TextView
    android:id="@+id/textView1"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Text View 1" />

<TextView
    android:id="@+id/textView2"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Text View 2"
    android:layout_marginTop="16dp" /> ✅Debugging: Here, you can adjust the alignment of views by using proper layout attributes like . gravity, layout_gravity, or layout_alignParent For example, to align the second with the first , you can use : TextView TextView layout_alignTop <TextView
    android:id="@+id/textView1"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Text View 1" />

<TextView
    android:id="@+id/textView2"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Text View 2"
    android:layout_alignTop="@+id/textView1" /> 👉🏿Unresponsive controls: It includes non-working UI features like buttons, input fields, or interactive elements that fail to respond to user interactions. ✅Debugging: To debug the unresponsive controls issues, try the following strategies: Verify interactions to ensure that user inputs and actions are properly handled and everything is in the expected behaviour. You can perform repeated regression testing to ensure that new changes or updates do not introduce issues into previously functioning interactions. Keep collecting user feedback and reports that provide valuable insights into the effectiveness and usability of the app's interactions. Examine UI blocking operations to confirm that interactions do not cause the app's user interface to freeze or become unresponsive. Check the event handlers to verify that the app correctly captures and processes user interactions (such as button clicks or gestures). Verify interactions to ensure that the app's intended functionality and user experience are consistently delivered to users. You can use several logging and debugging tools like for debugging the unresponsive control. P.S.: Selenium, Appium, JUnit, TestNG, and Chrome DevTools 👉🏿Inconsistent rendering: Rendering refers to the process involved in the generation of a 2D or 3D image from an app program. UI elements that display differently across different devices or screen sizes can lead to a lack of visual consistency and that will often be problematic. As shown in the figure, the app is not performing properly on specific devices. ✅Debugging: Try the following strategies: Reproduce the issue to understand and investigate the problem thoroughly. You can test the app on different devices and OS versions to ensure compatibility and identify any device-specific issues. Checking layout files ensures proper arrangement and responsiveness across various screen sizes and orientations so it is important to prefer and also manage density independence to ensure. Handling multiple screen sizes involves adapting the UI layout and elements to provide a consistent experience on different devices. Check resource files to guarantee that all necessary assets are present and correctly referenced in the app and review custom views or custom drawable to ensure their correct implementation and proper rendering in an app. Consider GPU rendering and hardware acceleration to optimize the app's graphics performance for smoother rendering. You can use a layout inspector or debugging tools to identify layout issues, view hierarchy, and UI rendering problems during debugging. Test the app with different themes and styles to ensure consistent and visually excellent user experiences across various design choices. User feedback and reports provide valuable insights into issues by allowing for prompt resolution and overall improvement. Regression testing ensures that new changes or fixes do not introduce new issues or disrupt previously working features or functionalities. You can use tools such as which are commonly used in the Android development ecosystem to assist with the mentioned tasks. P.S.: Firebase Test Lab, AWS Device Farm, Android Studio's Layout Editor, Device File Explorer, Android Profiler,  and bug tracking systems 👉🏿Performance issues: App performances get affected due to various factors such as . slow animations, sluggish scrolling, and delays in response time ✅Debugging: Try the following strategies: You could define the performance metrics to allow for the measurement and evaluation of the app's efficiency and responsiveness and also identify the performance hotspots to detect the affected areas of the code that require optimization for improved performance of the app. Monitor memory usage to ensure efficient memory management and identify any memory-related issues or leaks if they persist. Optimize UI rendering to enhance the app's responsiveness and also evaluate network operations to assist in identifying and optimizing potential bottlenecks by reducing latency and improving overall app performance for a better user experience. Next, analyze database queries to ensure efficient data retrieval and manipulation by optimizing app performance. To check parallel execution and synchronization-related issues, Check threading and concurrency. Optimize resource usage (such as CPU and battery consumption) to improve the app's performance and Keep analyzing third-party libraries ensures they are optimized and compatible by minimizing their impact on app performance. Gather user feedback regularly and utilize analytics which provides valuable insights to identify performance issues and prioritize improvements. You can use tools like for performance analysis, monitoring, and testing purposes. P.S.: Android Profiler (Android Studio), Firebase Performance Monitoring, Android Profiler, Xcode Instruments, LeakCanary, Android SQLite Profiler, iOS Core Data Profiler, Android Studio Debugger, Xcode Debugger, and Google Analytics 👉🏿Accessibility problems: Adoption of the app is determined based on how easier it is for any sort of user so, UI elements that are not accessible to users with disabilities can limit the app's usability. ✅Debugging: To address the app accessibility problem, try the following: To ensure inclusivity, it is important to understand accessibility guidelines and standards so, manual testing with assistive technologies can help to identify potential accessibility barriers. Check keyboard navigation to ensure that users can interact with the app using only the keyboard. Accessibility testing tools can automate the detection of common accessibility issues. Provide alternative text for images to enable users with visual impairments to understand their content and verify colour contrast to ensure readability and accessibility for users with low vision. Use semantic markup to enhance the accessibility and understanding of the UI elements of an app. Test voice guidance and feedback to guarantee an inclusive experience for users relying on screen readers. Consider focus management to ensure smooth and intuitive navigation for the keyboard and assistive technology. Seek user feedback and conduct usability testing with individuals using assistive technologies which help to identify accessibility improvements and also keep updating the app. To ensure inclusivity and accessibility, you can use different tools like for preferring the above strategies. P.S.: Axe or Lighthouse, Contrast Checker, Accessibility Inspector, and Accessibility Scanner ⬇️Complex Bugs: Complex issues can arise in the mobile app and sometimes, they remain unnoticed for a long time. Here are some illustrative code examples as the solution for such cases. 👉🏿Slow or Stuttering Scrolling: Probably you have also faced slow scrolling while using some mobile apps through a long list of complex UI. This is due to the bugs associated with the app UI system. ✅Debugging: You might love to use view recycling and asynchronous loading of data techniques to optimize the list or rendering. Here is a code sample. UI RecyclerView recyclerView = findViewById(R.id.recyclerView);
recyclerView.setLayoutManager(new LinearLayoutManager(this));

List<String> dataList = getData(); // Retrieve data for the list

MyAdapter adapter = new MyAdapter(dataList);
recyclerView.setAdapter(adapter); 👉🏿Unresponsive or Laggy UI Interactions This can be the most annoying issue as several UI elements or actions (such as button clicks) take a long time to respond or go unresponsive. ✅Debugging: One of the effective solutions is to move time-consuming tasks or heavy computations to background threads to keep the UI thread responsive for an enhanced user experience. Here is a code sample: Button myButton = findViewById(R.id.myButton);
myButton.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View v) {
        // Perform time-consuming task on a background thread
        new Thread(new Runnable() {
            @Override
            public void run() {
                // Perform the task
                // ...

                // Update UI on the main thread if needed
                runOnUiThread(new Runnable() {
                    @Override
                    public void run() {
                        // Update UI elements
                        // ...
                    }
                });
            }
        }).start();
    }
}); 📥How to avoid some common UI design mistakes? If you are focused on designing the best and most attractive app, care to start from the small details or elements. To give the best impressions to users, it is really crucial to avoid some common UI design mistakes which are as follows: 👉🏿Unclear Form: Some confusing forms result in users leaving the app from the very first stage. The form is the first thing that the user starts a journey to the app after creating an account. As shown in the following diagram, just showing an message for an incorrect password could make the user confused. “Error” ✅Solutions: Just using the “ ” indicator may not give an exact clue to the users, try offering detailed clues to take action like “ ”. Red Colour Password Reset 👉🏿Poor touch target Poor touch targets could make users frustrated while accessing the app functionalities. Have a look at the following figure. An option (say play button) provided on the left side is too small to click. ✅Solutions: Make finger-friendly touch targets by enabling the size best suited for any sort of user. 👉🏿Bad icons selection and placement: Unmanaged and wrong icon selection is another UI design mistake. Irrelevant and different-sized icons cannot give a better user experience. ✅Solutions: Use high-quality vectors for your app icons that look sharp with proper contrast. Try to choose a meaningful icon. For example, in the above figure, an icon for music (on the left side) is wrong and icon sizes are not looking to be matched. 👉🏿Too many features Sometimes, including too many features in an app could be problematic as some specific devices may not handle them due to the limitations in the hardware and software resources. It causes several issues like complexities and slow loading UI to affect the overall performance of the app. ✅Solutions: For the best practice, you might try offering the limited features correctly to the users. If your business app should consist of so many features then you can try to include them in the regular updates without breaking the customer relations and trust. 👉🏿Poor IA Here, IA stands for Information Architecture. Generally, most UI designers do not care to include the proper information in the app features. Users may not love to spend much time understanding the app features and functionalities of the information infrastructure that are not properly implemented in the app. ✅Solutions: Perform the research to understand the user’s interests and prioritize the information management systems in your app features and functionalities. For example, you can adjust a note to tell the function about some target elements. Challenges When Debugging UI issues Debugging app UI issues can sometimes be challenging due to various factors like the complexity of modern UI frameworks, variations in devices and browsers, and the inherent difficulty of reproducing and isolating the issues. Here are some common challenges you might encounter when debugging UI issues as shown in the diagram. Conclusion: A well-executed UI design is essential for capturing and retaining users' attention as it influences their perception of the app's quality, usability, and overall satisfaction. By focusing on creating a well-decorated, visually pleasing, and accessible UI, app developers can enhance user engagement, and encourage mass app usage or adoption. in mobile apps requires proper expertise and a thorough understanding of common to complex problems. By utilizing logging, testing, analyzing performance, and employing appropriate debugging tools, developers can effectively identify, diagnose, and resolve UI-related issues. Remember, proactive debugging and continuous improvement of the UI are crucial to maintain user satisfaction and driving the success of mobile apps. Debugging UI issues

Debugging User Interface (UI) Issues in Mobile Apps: A Comprehensive Guide

Churches Are Breaking the Law and the IRS Isn't Doing Anything About It

Polygon is a new web browser for smartphones, it is set to revolutionize how we use Ethereum. The network has already received much attention from the community. In fact, big companies like Nike, Reddit, and Starbucks adopted the blockchain-powered solution. So, what exactly makes it so special? Well, let me give you a fuller runover. The Rise Of Polygon Network Polygon is a new Ethereum-based network created by some of the brains behind the second-biggest cryptocurrency in history. Its main goal is to make Ethereum faster and cheaper while making it easier for users. The blockchain was previously named as the MATIC network, but in February 2021, it rebranded to the Polygon network. Currently, MATIC is an token on the Ethereum blockchain serving as the native token for Polygon. ERC20 The investments and big collaborations in Polygon also fostered its growth. For instance, its partnership with the consulting wing of Infosys Limited, . The partnership would enable Infosys to provide emerging technology services to its customers and M-Setu would become an open-source bridge for brands to cross-operate on the Ethereum blockchain. M-Setu On May 25, 2021, the billionaire crypto investor, Mark Cuban shared that he has invested in Polygon and this is still visible in his on the Mark Cuban companies website. He said that Polygon has a high transaction per second TPS and that is important to reduce the transaction cost for users. On May 28, Polygon made a huge announcement of which would allow the users of Big Query to adopt Polygon thereby, increasing its flexibility and brand positioning. company’s portfolio integrating its asset into Google Cloud’s Big Query What is the hype all about? Recently, there has been so much hype building around the Polygon blockchain, it is considered a potential game changer in the world of dApps. Well, that is because it is the first Ethereum 2.0 network with more flexibility and accessibility. The network will be faster than Ethereum and cheaper to run, in fact, its cost per transaction could be as low as $1. Also, Polygon uses a new technology called C++ scala that makes it possible for developers to write their code once, then compile it into multiple languages like Java or JavaScript and run it on any computer system without needing any special hardware if you have an internet connection (and sometimes even when you don’t). The Polygon hype doubled when to help creators mint and sell Polygon NFTs (Non-Fungible Tokens) on . Meta partnered with polygon Instagram In addition, for a technology that once struggled to raise funds, Polygon started to attract the interest of venture capitalists with its innovative technology. In February 2022, it raised in India. Through a private sale of its native token, MATIC, to expand its scaling solutions and improve operations. $450m from Sequoia Capital Polygon vs Ethereum: What is the difference? The Polygon Network is a new blockchain that will be faster and cheaper than Ethereum, but it also has some advantages over Ethereum itself. Polygon is an open-source project, meaning anyone can contribute code or otherwise help make it better by providing feedback on how they can improve their own experience with the network itself. They are not just going through the motions when creating this new product, they really want people who are using it now - whether it is as part of their everyday lives or just because they like what this platform stands for - to feel involved in its development process as well. The difference between Polygon and other cryptocurrencies like Bitcoin or Litecoin is that instead of using Proof-Of-Work (POW) to confirm transactions, it uses delegated proof-of-stake (DPOS). DPOS allows anyone with enough stake in the network (which means holding at least 10% of all tokens) to vote on who will be chosen as block producers or validators. The more coins you hold within Polygon networks, the greater chance you have of being selected as the next block candidate during POS voting rounds. If you are selected as the winner then the transaction fees will be paid out into your account as rewards. This allows the producers to have greater control over how much power they have over the network. Also, this is more incentive than other cryptocurrencies offer since the block producers get paid based on how many blocks they produce each day instead of being rewarded for solving difficult puzzles. Although, unlike the Ethereum network which is more private and secure, Polygon is more decentralized. However, this gives it better scalability than Ethereum because Polygon counterbalances lesser security with its flexibility. This does not mean that the polygon network is entirely unsafe, just that it is not as secure as its layer1 blockchain (Ethereum). Conclusion Many people do not understand Ethereum and what it does, but Polygon should be a good way for them to get into blockchain. The company is making progress and has already launched new products that will make blockchain transactions faster than ever before without any transaction fees or stress. This means that people who want to get involved with cryptocurrency will have no excuse but to use Polygon as their go-to site when they need their things done quickly. Also published here.

What’s All the Polygon Hype About?

Ransomware is one of the most dangerous threats to many industries and businesses nowadays. Ransomware attacks cause material losses amounting to millions of dollars per year worldwide, and this amount is growing year after year. There are different ransomware families, and Cerber ransomware is one of the most devastating. This blog post covers Cerber ransomware, infection methods, the working principle, how to remove Cerber ransomware, and how to protect against Cerber. The typical behavior of Cerber is explained to help prevent and deal with this dangerous type of ransomware. General Information About Cerber Ransomware What is Cerber ransomware? Cerber is a type of ransomware that infects computers and encrypts files. Cybercriminals then demand victims pay ransom in bitcoins to receive a key that releases the files. However, there is no guarantee that a victim can get the data back after paying a ransom. The first version of Cerber ransomware was created in 2016. In 2018, it seemed that Cerber attacks had stopped. But in 2020, Cerber came back, and new attacks were launched with updated versions of this ransomware. Cerber ransomware uses the ransomware as a service (RaaS) model for distribution. Cerber is highly customizable ransomware. Ransomware attackers can become affiliates, use ransomware provided by Cerber developers, and split the ransom (pay about 40% of the received ransom money) to the Cerber developers. This approach allows cybercriminals to launch more attacks with less work. The statistics on ransomware infections are staggering. More than 52 million attacks were launched in the first half of 2021. Both enterprises and individual users are being targeted. Organizations in diverse industries were targets of ransomware attacks with Cerber. No one is safe from Cerber ransomware. Examples of how antivirus software detects Cerber: Win32/Filecoder.Cerber.B Ransom.Cerber Ransom:Win32/Cerber Win-Trojan/Cerber.Gen RANSOM_CERBER Trojan.GenericKDZ.39212 NSIS/Ransom-Cerber.a How Cerber Ransomware Works Sophisticated techniques are used to infect computers and encrypt files. Let’s explain how victims are infected to understand infection vectors and how to protect against Cerber ransomware. Spam, malvertising (malware-infected ads on websites), exploit kits, and exploitation of vulnerable websites are methods to infect computers. The main attack vector is spam and phishing emails sent to victims. An email message contains text that manipulates a victim and tricks them into opening an attached file. Attackers use social engineering to compose an email that seems legitimate, for example, an email from a bank, delivery service, etc. Usually, a Word document with malicious macros is attached to the email message. Microsoft Office Exploits can be used. When a user opens the infected DOCX file, the macro in the document writes a piece of Visual Basic Script (VBScript) into memory and executes this script. The VBScript initiates running PowerShell in hidden mode and can bypass PowerShell execution policies. The command is executed in PowerShell for connecting to a malicious site and downloading the Cerber ransomware payload. If the connection is successful, then an executable Cerber file is downloaded to the computer and executed in PowerShell. There are Cerber versions that use JavaScript instead of VBScript. The malware file hash can change every few seconds to a newer timestamp with appending data bytes to avoid being detected by using hash-based methods. A double-zipped file, such as a self-extracting archive (SFX), with a malicious Windows Script File (WSF) is another variation of the attached file. A phishing email can contain an unsubscribe link that redirects to the same malicious Cerber file. The archive contains three files: A66K.DLL N3W7MN.VBS X There are versions of Cerber ransomware with installers that contain a .ch file and .caz shellcode file with the code to decrypt the executable .ch file. In this case, Cerber uses Nullsoft Scriptable Install System to hide. Note that file names, file locations, configuration formats, and other parameters can change with the release of new versions of Cerber ransomware. Wscript.exe is used to run the VBScript that executes a DLL export through rundll32.exe, which decrypts data from the X component and executes malicious code. The X component is completely encrypted. The first encrypted part is loaded from X and is used to check techniques for reversing analysis and research of Cerber ransomware (anti-emulation and anti-debugging techniques). The second part of the X component is extracted and injected into Regasm.exe or WerFault.exe, where it is hidden. This second component checks for .NET Framework. If .NET Framework is found, Cerber checks the version of the framework and injects a malicious code. If .NET Framework is not found, Cerber injects code into WerFault.exe. Thus Cerber ransomware can infect both 32-bit and 64-bit Windows operating systems. Anti-emulation techniques Cerber checks files and directories that can indicate that it’s running inside virtual machines (VMs) or sandbox environments to make researching more difficult for security experts. Cerber checks for anti-virus and anti-malware software by checking directories that can indicate that this software is installed. Cerber checks whether a traffic analyzer (sniffer) like WireShark is installed. Cerber checks whether it’s running inside a virtual machine under a VMware, Hyper-V, VirtualBox, QEMU, or Parallel virtualization platform. In order to check whether Cerber ransomware is running on a VM, Cerber checks the registry key: HKLM\SYSTEM\CurrentControlSet\Enum\PCI Each subkey in this registry key represents a Peripheral Component Interconnect (PCI) device installed for the machine by using this format: VEN_XXXX&DEV_XXXX&SUBSYS_XXXXXXXXX&REV_XX VEN represents a Vendor ID, DEV represents a Device ID in the hexadecimal format (HEX). When hardware virtualization is used, hardware devices are emulated. Virtual devices use the appropriate Vendor IDs and Device IDs, depending on the hardware virtualization platform on which the VM is running. If Cerber ransomware detects that Cerber is running in a VM, the ransomware terminates itself. However, you still need to regularly perform VM backup. Cerber also tries to find the VMware substring that indicates that it’s running inside the VMware VM and strings pointing to the VMs of other vendors in the registry key: HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\SystemBiosVersion Configuration Cerber ransomware is highly configurable. Lists and tags are defined as configuration parameters. A list of blacklisted countries in the JavaScript Object Notation (JSON) format is created to avoid infecting computers that are connected to the internet by using the IP addresses of these countries. Cerber identifies the country by checking the public IP address of the potential victim. The system keyboard layout is also checked to avoid infecting computers from the blacklisted countries. The countries excluded from ransomware attacks in the Cerber configuration are Russia and some neighboring countries. Security researchers presume that Cerber creators were located in Russia and wanted to target developed countries to get more money from victims. An attack is avoided if Cerber detects that one of these keyboard layouts is installed as the system keyboard layout on a computer: 1049—Russian, 2115—Uzbek (Cyrillic), 2092—Azeri (Cyrillic), 1068—Azeri, (Latin), 2073—Russian (Moldova), 2072—Romanian (Moldova), 1091—Uzbek (Latin), 1090—Turkmen, 1088—Kyrgyz (Cyrillic), 1087—Kazakh, 1079—Georgian, 1067—Armenian, 1064—Tajik, 1059—Belarusian, 1058—Ukrainian. Once executed, Cerber ransomware checks the directory from which the ransomware has been launched. If Cerber is not launched from %APPDATA%\&#60GUID&#62, then a copy of the Cerber file is created in the %APPDATA% directory of a user on a Windows machine. The file name is selected randomly by using one of the file names in the %WINDIR%\system32 directory for better masquerading. Bypassing Windows protection Bypassing Windows protection and changing Windows configuration is another part of Cerber’s aggressive behavior. User Access Control (UAC) checks are bypassed. Cerber ransomware deletes Volume Shadow Copies to disable Windows restore options and disables safe boot options to avoid repairing Windows after infection. Vssadmin.exe "delete shadows /all /quiet" WMIC.exe "shadowcopy delete" Bcdedit.exe "/set {default} recoveryenabled no" Bcdedit.exe "/set {default} bootstatuspolicy ignoreallfailures Cerber performs multiple manipulations to make the configuration persistent, run encryption after reboot, and display notifications after finishing file encryption: Adding a task in Windows Scheduler. The tasks are stored in %WinDir%\Tasks or %WinDir%\System32\Tasks. Changing the CommandProcessor autorun key value for pointing to the Cerber payload. After that, ransomware is executed each time CMD.exe is launched. Editing a registry key to launch ransomware instead of a screensaver. Run and runonce keys are also used. A shortcut file (LNK) that references the ransomware is added to the Startup directory. As a result, Cerber ransomware executes automatically after a user logs into Windows. Connecting to external servers on UDP port 6893, sending encrypted information, and saving some received encrypted information to the disk is performed when preparing to encrypt files. At this time, Cerber ransomware can encrypt 294 file extensions. This number has significantly increased compared to the first version of Cerber. File encryption AES-256 (RSA-2048) and RC4 encryption algorithms are used to encrypt files that are accessed from the infected computer. A 256-bit key is generated on the victim’s computer and then protected with a 2048-bit key. AES encryption is asymmetric – encryption and decryption keys are different. The encryption key is a public key and the decryption key is a private key. The decryption key is needed to decrypt the encrypted files, but the decryption key cannot be generated if the encryption key is available. Cerber initiates killing processes that have opened files because the opened file is locked by an application using this file and ransomware cannot encrypt this file. Cerber attempts to close database software to encrypt database files. This ransomware can also close applications like Word, Excel, and others to encrypt documents that are opened. The list of the processes that can be killed is defined in the Cerber configuration with the close_process list tag. Cerber encrypts accessible files (that have supported file extensions) including network disks and file shares. Encrypted files cannot be opened as usual if you rename file extensions. Encrypted files have extensions like: .cerber, .cerber2, .cerber3, .af47, .a48f, .ba99, .beef, or random characters. Random names make it more difficult to scan and find the files that were encrypted. There is a known algorithm for how these random file extensions are generated. Cerber ransomware checks this registry entry before generating the extension that will be used for encrypted files: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid The format of MachineGuid is the following: XXXXXXXX-YYYY-ZZZZ-AAAA-BBBBBBBBBBBB Eight characters in the first part (XXXXXXXX in this example) are used to generate a directory name for Cerber in the %TEMP% folder. Four characters in part 2 and part3 (YYYY, ZZZZ) are used to name Cerber component files. Four characters in part 4 (AAAA) are used to name the extensions of the encrypted files. System files of an operating system (OS) are not encrypted to allow OS to boot and display the ransom note. Once the file encryption has finished, the desktop wallpaper is changed and additional ransom notes are added in .txt, .vbs, .hta, and .html files on the desktop and in other folders. Cerber ransomware kills itself (kills the task in CMD or PowerShell), and the original payload executable files are hidden or deleted after finishing encryption. Examples of the note files: README.hta _READ_THIS_FILE.hta # HELP DECRYPT#.html # DECRYPT MY FILES #.txt # DECRYPT MY FILES #.html HELP_HELP_HELP[random characters].hta _R_E_A_D___T_H_I_S___[random]_.txt _R_E_A_D___T_H_I_S___[random]_.hta These notes contain a link to download the TOR browser, a link to the website on the dark web, where payment can be made, and instructions. The text notification can be accompanied by an audio message when opening the VBS file. Notes are provided in 12 languages including English, German, Spanish, French, Italian, Polish, Turkish, Dutch, Japanese, and Chinese. Attackers demand the victim pay a ransom within 7 days. After 7 days have passed, the price is doubled. New versions of Cerber can add an infected computer to a botnet used for distributed denial of service (DDoS) attacks and other illegal activities. This tactic allows attackers to get an advantage even if the victim doesn’t pay the ransom. What to Do if a Computer is Infected? If you see that a computer is infected with Cerber ransomware, take these actions: Don’t pay a ransom because paying the ransom finances cybercriminals and inspires them to launch more attacks. Disconnect the infected computer from the network. Power off the computer to stop encryption (if the encryption is in progress). These actions can avoid infecting other computers connected to the network. Report the ransomware to the authorities. Remove Cerber ransomware. Try to recover corrupted files. How to Remove Cerber Ransomware In order to remove Cerber ransomware, follow these steps: Boot from a Live DVD, because the installed OS infected with ransomware cannot work properly. Scan files on the infected computer with antivirus software. Delete the infected files. How to Recover Files Encrypted with Cerber Ransomware Unfortunately, removing Cerber ransomware doesn’t recover encrypted files. Try to perform these actions for file recovery: Search for a decryption tool. Some decryption tools were published for the first versions of Cerber ransomware. Later, cybercriminals modified Cerber to avoid decryption. If there is no decryption tool and decryption is not possible, leave the disk drives with corrupted files in the archive. A decryption tool probably will be released at some point. Try to use software to restore deleted files. If you have a data backup, restore the needed files from the backup. It is recommended that you reinstall the OS that was infected with Cerber ransomware because the infected OS will not function properly. A better method is to recover a partition with the OS from a backup image. How to Protect Against Cerber Ransomware The strategy for protecting against Cerber ransomware is similar to the general strategy of ransomware protection. Educate users not to open suspicious links, emails, and file attachments. Use anti-malware protection on an email server. Organizations using Office 365 can use Exchange Online Protection and Advanced Threat Protection. Install anti-virus software on computers and regularly update anti-virus databases. Patch software vulnerabilities when software updates are released. Respect the security policy and provide writing access to shared files only for those who need it. Back up your data regularly and respect the . Restrict access to backups. If you store backups on media that is offline (for example, on a disconnected hard disk drive or a tape cartridge), ransomware cannot access and corrupt the data of backups. 3-2-1 backup rule Conclusion Cerber ransomware is extremely dangerous because this ransomware can corrupt most files on a computer. Knowing the behavior and working principles of Cerber can help you detect this ransomware. This blog post has covered Cerber ransomware and explained how Cerber works, how to remove Cerber ransomware, how to protect against Cerber attacks, and how to recover data if files were corrupted. The most effective methods to protect your files against ransomware are preventive measures. Use antivirus protection, patch vulnerabilities, educate users, configure user access to resources properly, and perform data backup regularly.

Runo

runo.in

51-200 employees

Since 2019

COMPANY RANKING

RUNO

EVERGREEN INDEX #9785

Runo WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

Runo

runo.in

51-200 employees

Since 2019

COMPANY RANKING

RUNO

EVERGREEN INDEX #9785

RELATED COMPANIESRANK

STORIES ABOUT RUNO

Runo WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!