Openjob is a new distributed task scheduling framework based on Akka architecture. Supports multiple cronjob, delay task, workflow, lightweight distributed computing, unlimited horizontal scaling, with high scalability and fault tolerance. Also has complete management, powerful alarm monitoring, and support multiple languages
Openjob is a new distributed task scheduling framework based on Akka architecture. Supports multiple cronjob, delay task, workflow, lightweight distributed computing, unlimited horizontal scaling, with high scalability and fault tolerance. Also has complete management, powerful alarm monitoring, and support multiple languages
If you are looking for a high-performance distributed task scheduling framework that supports cronjob, delay task, lightweight computing, workflow, and supports multiple programming languages, then Openjob is definitely the way to go.
gookit/goutil An extended library of Go's common functionality. Contains: number, string, slice/array, Map, struct, reflection, text, file, error, time and date, test, CLI, command run, system information, formatting, common information acquisition, etc.
Openjob is a distributed and high-performance task scheduling framework that supports multiple cronjob, delay task, workflow, lightweight distributed computing, unlimited horizontal scaling, with high scalability and fault tolerance. Also has perfect permission management, powerful alarm monitoring, and support multiple languages
This is a translation of my article in Russian
In this article, I want to write about my experience of interacting with the LeetCode platform, and describe my preparation for an interview in FAANG similar companies by breaking it down into levels.
The whole article is written based on my experience, the numbers are very rough, I do not pretend to be objective, perhaps there are best practices on how to solve LeetCode problems, it would be cool if you share your experience in the comments.
This is a series of articles dedicated to the optimal choice between different systems on a real project or an architectural interview.
At work or at a System Design interview, you often have to choose the best message broker. I plunged into this issue and will tell you what and why. What is better in each case, what are the advantages and disadvantages of these systems, and which one to choose, I will show with several examples.
This is a series of articles dedicated to the optimal choice between different systems on a real project or an architectural interview.
This topic seemed relevant to me because such tasks can be encountered both at work and at an interview for System Design Interview and you will have to choose between these two types of DBMS. I plunged into this issue and will tell you what and how. What is better in each case, what are the advantages and disadvantages of these systems and which one to choose, I will show with several examples at the end of the article.
SQL or NoSQL?
1) OpenTracing (OT) != Logs but they are very similar.
2) Every application has 2 types of scopes: ApplicationScope (AScope) and RequestScope (RScope).
This is an article that describes my vision of building a system that actively uses Go as the main programming language and SOA/microservices as a design paradigm.
Here I will try to cover 4 chapters that together allow us to build a solid and reliable system.
JiraCLI is an interactive command line tool for Atlassian Jira that will help you avoid Jira UI to some extent. This tool is not yet considered complete but has all the essential features required to improve your workflow with Jira.
The tool started with the idea of making issue search and navigation as straightforward as possible. However, the tool now includes all necessary features like issue creation, cloning, linking, ticket transition, and much more.
The tool supports both jira cloud and on-premise jira installation since the latest release.
One of the nicest features of Go is the power of code generation. go generate command serves as a Swish knife allowing you to generate enums, mocks and stubs. In this article, we will employ this feature to generate a Go code from OpenAPI specification. OpenAPI specification is a modern industrial standard for REST API. This standard has fantastic tooling support and allows you to conveniently render and validate the spec. We are going to befriend the power of Go code generation with the elegance and clarity of the OpenAPI specification. In this way, you don't have to manually update the Go boilerplate code after every change in the spec. You also ensure that your docs and your code are a single entity, as your code is being begotten from the docs.
Let's start dead-simple: we have a service that accepts order requests. Let's declare endpoint order/10045234 that accepts PUT requests, where 10045234 is an ID of a particular order. We expect to receive an order as a JSON payload in the following format.
{"item": "Tea Table Green", "price": 106}How can describe this endpoint in the OpenAPI spec?
In this series, I would like to discuss some reaches of Go programming language. There is no shortage of Go-Language-Of-Cloud style articles in which you can explore the great benefits that Go indeed provides. However, there are lees to every wine, and Go does not go without blemish. In this highly opinionated series, we cover some controversies and, dare I say, pitfalls of the original Go design.
We start tough and begin with the essence of Go — it's inbuild data types. In this article, we put slice to the test. Let's move a step further from the Go Tour and use slice more extensively. For example, there is no separate data type as stack in Go, because slice type is intended to cover all its usage scenarios.
Let's briefly recap the usage of the stack. We can create a stack in two seconds using a couple of paper stickers. You write "buy milk" on the first sticker and put at the desk, and then "make the dishes" on the second and pile it on the first sticker. Now, you have a stack: the dishes sticker came last but will be served first, as it is on the top of the stack. Thus, there is an alternative name for stack — LIFO, Last-In-First-Out. To compare, there is the "opposite" data structure queue or FILO — first in, first out. In programming, stacks are everywhere, either in the explicit form or in the implicit as stack trace of the execution of a recursive function.
Ok, let's put slice into use and implement stack.
This article is a part of Algorithms in Go series where we discuss common algorithmic problems and their solution patterns.
In this edition, we take a closer look at bit manipulations. Bit operations can be extremely powerful and useful in an entire class of algorithmic problems, including problems that at first glance does not have to do anything with bits.
Let's consider the following problem: six friends meet in the bar and decide who pays for the next round. They would like to select a random person among them for that. How can they do a random selection using only a single coin?
The solution to this problem is not particularly obvious (for me:), so let's simplify a problem for a moment to develop our understanding. How would we do the selection if there were only three friends? In other words, how would we "mimic" a three-sided coin with a two-sided coin?
In this series, we will be discussing interesting aspects and corner cases of Golang. Some questions will be obvious, and some will require a closer look even from an experienced Go developer. These question will help to deeper the understanding of the programming language, and its underlying philosophy. Without much ado, let's start with the first part.
What value y will have at the end of the execution?
func main() {
var y int
for y, z := 1, 1; y < 10; y++ {
_ = y
_ = z
}
fmt.Println(y)
}
According to the specification,
Most solutions to algorithmic problems can be grouped into a rather small number of patterns. When we start to solve some problem, we need to think about how we would classify them. For example, can we apply fast and slow аlgorithmic pattern or do we need to use cyclic sortpattern? Some of the problems have several solutions based on different patterns. In this series, we discuss the most popular algorithmic patterns that cover more than 90% of the usual problems.
It is different from High-School Algorithms 101 Course, as it is not intended to cover things like Karatsuba algorithm (fast multiplication algorithm) or prove different methods of sorting. Instead, Algorithmic Patterns focused on practical skills needed for the solution of common problems. For example, when we set up a Prometheus alert for high request latency we are dealing with Sliding Window Pattern. Or let say, we organize a team event and need to find an available time slot for every participant. At the first glance, it is not obvious that in this case, we are actually solving an algorithmic problem. Actually, during our day we usually solve a bunch of algorithmic problems without realizing that we dealing with algorithms.
The knowledge about Algorithmic Patterns helps one to classify a problem and then apply the appropriate method.
But probably most importantly learning algorithmic patterns boost general programming skills. It is especially helpful when you are debugging some production code, as it trains you to understand the execution flow.
Patterns covered so far:
Stay tuned :)
<Promo> If you interested to work as a backend engineer, there is an open position in my squad. Prior knowledge of Golang is not required. I am NOT an HR and DO NOT represent the company in any capacity. However, I can share my personal experience as a backend engineer working in the company. </Promo>
In this article, we discuss the postorder traversal of a binary tree. What does postorder traversal mean? It means that at first, we process the left subtree of the node, then the right subtree of the node, and only after that we process the node itself.
Why would we need to do it in this order? This approach solves an entire class of algorithmic problems related to the binary trees. For example, to find the longest path between two nodes we need to traverse the tree in a postorder manner. In general, postorder traversal is needed when we cannot process the node without processing its children first. In this manner, for example, we can calculate the height of the tree. To know the height of a node, we need to calculate the height of its children and increment it by one.
Let's start with a recursive approach. We need to process the left child, then the right child and finally we can process the node itself. For simplicity, let's just save the values into slice out.
Most solutions to algorithmic problems can be grouped into a rather small number of patterns. When we start to solve some problem, we need to think about how we would classify them. For example, can we apply fast and slowalgorithmic pattern or do we need to use cyclic sortpattern? Some of the problems have several solutions with different patterns. In this article of series Algorithms in Go we consider an algorithmic pattern that solves an entire class of the problems related to a matrix. Let's take one of such problems and see how we can handle it.
How can we traverse a matrix in a spiral order?
The flag of the Netherlands consists of three colors: red, white and blue. Given balls of these three colors arranged randomly in a line (it does not matter how many balls there are), the task is to arrange them such that all balls of the same color are together and their collective color groups are in the correct order.
For simplicity instead of colors red, white, and blue we will be dealing with ones, twos and zeroes.
Let's start with our intuition. We have an array of zeroth, ones, and twos. How would we sort it? Well, we could put aside all zeroes into some bucket, all ones into another bucket, and all twos into the third. Then we can fetch all items from the first bucket, then from the second, and from the last bucket, and restore all the items. This approach is perfectly fine and has a great performance. We touch all the elements when we iterate through the array, and then we iterate through all the elements once more when we "reassamble" the array. So, the overall time complexity is O(n) + O(n) ~= O(n). The space complexity is also O(n) as we need to store all items in the buckets.
Can we do better than that? There is no way to improve our time complexity. However, we can think of a more efficient algorithm in regard to space complexity. How would we solve the problem without the additional buckets?
Let's make a leap of faith and pretend that somehow we were able to process a part of the array. We iterate through part of the array and put encountered zeroes and ones at the beginning of the array, and twos at the end of the array. Now, we switched to the next index i with some unprocessed value x. What should we do there?
All Prometheus metrics are based on time series - streams of timestamped values belonging to the same metric. Each time series is uniquely identified by its metric name and optional key-value pairs called labels. The metric name specifies some characteristics of the measured system, such as http_requests_total - the total number of received HTTP requests. In practice, you often will be interested in some subset of the values of a metric, for example, in the number of requests received by a particular endpoint; and here is where the labels come in handy. We can partition a metric by adding endpoint label and see the statics for a particular endpoint: http_requests_total{endpoint="api/status"}. Every metric has two automatically created labels: job_name and instance. We see their roles in the next section.
Prometheus provides a functional query language called PromQL. The result of the query might be evaluated to one of four types:
Scalar (aka float)
String (currently unused)
Instant Vector - a set of time series that have exactly one value per timestamp.
Range Vector - a set of time series that have a range of values between two timestamps.
At first glance, Instant Vector might look like an array, and Range Vector as a matrix.
If that would be the case, then a Range Vector for a single time series "downgrades" to an Instant Vector. However, that's not the case:
What is distributed tracing? Distributed tracing is a method used to profile and monitor applications, especially those built using a microservices architecture. Distributed tracing helps pinpoint where failures occur and what causes poor performance.
Let’s have a look at a simple prototype. A user fetches information about a shipment from `logistic` service. logistic service does some computation and fetches the data from a database. logistic service doesn’t know the actual status of the shipment, so it has to fetch the updated status from another service `tracking`. `tracking` service also needs to fetch the data from a database and to do some computation.
In the screenshot below, we see a whole life cycle of the request issued to `logistics` service: