The next technology development cycle ... the common blocks—or tools and data—that can serve at a cross-sector level. When data is harnessed digitally, it becomes easier and more functional to apply it across our business and engagement life cycle ...

Driving innovation through disruptive technology

Peel Hunt, a UK investment bank, has appointed Piya Khanna as its Chief Technology Officer (CTO). Khanna brings over 20 years of experience in delivering business efficiencies and transformation via technology, product development, technology ...

ON THE MOVE: Piya Khanna Joins Peel Hunt; SymphonyAI Adds Blythe Masters

The cross-functional team participates in the so-called PNT Assessment Experiment, which puts both emerging and established tech through the wringer ... namely Cold War cleanup and nuclear weapons development — for a daily newspaper in South Carolina.

Suppressed GPS in Ukraine fuels development of US Army navigation tech

Siemens Digital Industries Software is bringing AI assisted design and greater cloud-based collaboration to Solid Edge 2024 software, product design and engineering software ... in the system such as synchronous technology’s ability to recognize and ...

Solid Edge 2024 expands-AI assisted design capabilities in Siemens Xcelerator

The creation of Mera Yuva Bharat (MY Bharat), an independent organization that would serve as a comprehensive technology-driven enabling mechanism to enable youth-led development, was approved by the Union cabinet on Wednesday. This is for the first time ...

“MY Bharat” a Tech-Driven Initiative Announced by the Government

Chennapragada brings with her a wealth of experience, having spent 12 years in leadership roles at Google, where she led teams in product development, engineering ... holds a B.Tech in Computer ...

Indian-American ex-Google exec Aparna Chennapragada to lead Microsoft’s generative AI efforts

Army planners with the service's newest cross-functional teams are considering development of a new class of small resupply and logistics USVs to handle those operations in the Indo-Pacific region ...

AUSA 2023: US land forces look to develop maritime surface vessel options for transporting people and equipment

The product ... technology company built to innovate, with a global, entrepreneurial-minded team of over 174,000 employees across 351 manufacturing operations and 103 product development ...

Magna Introduces Industry-First, 100% Melt Recyclable Foam and Trim Seating Solutions

Have you ever wondered about the fascinating journey your car takes from a mere concept to a powerful machine on the road? Behind every sleek design and impressive engine lies an intricate web of professionals who bring automobiles to life.

From Design to Manufacturing: The Diverse Roles in Automobile Technology Careers

We are a mobility technology company built to innovate, with a global, entrepreneurial-minded team of over 174,000 employees across 351 manufacturing operations and 103 product development, engineering and sales centers spanning 30 countries. With 65 ...

inDrive.Tech

indrivetech

Learn how inDrive’s bug bounty program strengthens cybersecurity by collaborating with white hat hackers to detect vulnerabilities and optimize security processes. Introduction In a world where digital technology is infiltrating every aspect of our lives, cybersecurity is of paramount importance. Companies around the world are investing heavily in protecting their data and systems from cyber threats. One of the most effective methods of strengthening security is to work with independent security experts, also known as “white hat hackers.” This article will be useful for companies that are planning to launch a bug bounty program or have already launched one. We will share our experience in organizing and developing the bug bounty program at inDrive and how it has helped strengthen our cybersecurity. We would also like to point out that you should not limit yourself to the bug bounty program, as it is not a panacea for solving all security problems. Bug bounty can help you identify some vulnerabilities, but it does not cover the full range of possible threats. You need to take a comprehensive approach to security that includes the use of various security tools and techniques. As the graph below shows, different tools detect different numbers of vulnerabilities, which emphasizes the importance of combining methods such as automated scanners, static and dynamic code analysis, security audits, and employee training. Beginning Initially, our bug bounty program worked in closed mode. This allowed us to control the flow of bughunters, gradually send out invitations and track the results. This approach gave us the opportunity to quietly debug and improve internal processes. Thanks to this, we were able to prepare for going public. Integration and Triage Identifying vulnerabilities in a bug bounty program is a key step. We use automatic integration with Slack and Jira to make this process fast and efficient. Slack We use two channels: The main channel for communicating key events in report processing. This includes notifications of new reports, task assignments to engineers, and vulnerability disclosure requests. This channel allows the team to always be aware of critical events. An additional channel is for employees involved in the initial analysis and triage of reports. Notifications of non-urgent activities such as report comments and triage details are sent here. Account Matching Setting up a mapping between HackerOne and Slack users ensures that important comments and report notes are directly delivered to the responsible parties, minimizing the risk of missing important information. This simplifies communication between the inDrive security team and researchers, facilitating more effective vulnerability remediation. Jira Integration with Jira allows you to create a task only in the right place with a specific set of fields. Using the Jira Automation functionality, we created our own task processing rules to improve our internal vulnerability handling processes, allowing us to efficiently organize this process. Below is an example of this automation: Found By Automation: The system automatically populates the Found By field with the bug bounty value, indicating the origin of the task for analytics. Task Assignment: Using rules, a task is automatically assigned to an engineer, ensuring even distribution of work. Slack Notifications: When a task is assigned, a notification is sent to Slack that mentions the engineer and provides all the necessary information. For critical vulnerabilities: Messages to a dedicated Slack channel: Notification of a critical vulnerability is sent to a separate channel for immediate response. Sending SMS messages: In addition, SMS notifications are sent to the responsible persons. Fighting Spam With Triggers Triggers in HackerOne are a powerful tool that allows you to automate various actions in response to certain events related to new vulnerability reports. They greatly simplify the work of the security team and help optimize the process of responding to reports. For example, when rebranding the company from inDriver to inDrive, we often encountered reports of problems with social media accounts. We customized the trigger as follows: Trigger condition: If the report contains words from the list: media, social, Facebook, Twitter, Instagram. Trigger action: When the specified condition is detected, a pop-up window with the following warning text is automatically displayed to the researcher: “Hi, it looks like you are about to report an issue with social media links (Instagram, Twitter, Facebook). Our company is in the process of rebranding and we are aware of this issue. We are temporarily not accepting reports for this issue, so we urge you to properly acknowledge the issue and familiarize yourself with the security policy before proceeding and submitting a report.” This not only helps to reduce the number of inappropriate reports but also educates researchers, improving the quality of future reports. Campaign and Telegram Channel We understood that over time the activity in the program would decrease. This is a natural process due to the fact that the most obvious vulnerabilities have already been found and eliminated, and attracting the attention of researchers again requires additional efforts. To maintain a high level of engagement and interest in our program, we took a number of measures. One of the key tools was our specialized Telegram channel for bughunters. This channel serves not only as a means of communication but also as a platform for sharing useful information. We actively share information about our application and provide materials that can help researchers find vulnerabilities in our services. This may be technical documentation, descriptions of new features, or architectural changes that may be of interest from a security point of view. Key benefits of our Telegram channel: Official updates: Direct and reliable news from the inDrive security team.
New Feature Announcements: Information about new services and features that may be of interest to bug bounty enthusiasts.
Promotions and Events: Information about special offers and events related to the bug bounty program. More information about the channel can be found by following the link — https://t.me/indrive_bbp. In addition, to attract both new and experienced bughunters, we regularly launch campaigns on the HackerOne platform. Campaigns allow us to stimulate bughunters’ interest in our program. We also announce all campaign launches via our Telegram channel, which allows us to quickly convey information to the audience and encourage them to participate. For example, below are statistics from one of the campaigns: These measures allow us to keep interest in the bugbounty program at a high level, ensuring a constant flow of fresh ideas and findings, which ultimately contributes to improving the security of our products. Our tips will help you dramatically improve your time to every stage of vulnerability processing — from time to first response to triage to time to bounty. And this, in turn, will increase the trust and satisfaction of the bug hunters participating in your program. In conclusion, our experience in organizing and developing a bug bounty program at inDrive is a vivid example of how hiring external security experts can significantly strengthen a company’s cyber defense. Thanks to our community of white hat hackers, we were not only able to identify and remediate many vulnerabilities but also optimized our internal processes, which increased our efficiency and improved the protection of our systems and data. We thank all participants of our bug bounty program for their invaluable contribution to inDrive’s security and invite new researchers to join our community. Together, we will make the digital world safer! Learn how inDrive’s bug bounty program strengthens cybersecurity by collaborating with white hat hackers to detect vulnerabilities and optimize security processes. Introduction In a world where digital technology is infiltrating every aspect of our lives, cybersecurity is of paramount importance. Companies around the world are investing heavily in protecting their data and systems from cyber threats. One of the most effective methods of strengthening security is to work with independent security experts, also known as “white hat hackers.” This article will be useful for companies that are planning to launch a bug bounty program or have already launched one. We will share our experience in organizing and developing the bug bounty program at inDrive and how it has helped strengthen our cybersecurity. We would also like to point out that you should not limit yourself to the bug bounty program, as it is not a panacea for solving all security problems. Bug bounty can help you identify some vulnerabilities, but it does not cover the full range of possible threats. You need to take a comprehensive approach to security that includes the use of various security tools and techniques. As the graph below shows, different tools detect different numbers of vulnerabilities, which emphasizes the importance of combining methods such as automated scanners, static and dynamic code analysis, security audits, and employee training. Beginning Initially, our bug bounty program worked in closed mode. This allowed us to control the flow of bughunters, gradually send out invitations and track the results. This approach gave us the opportunity to quietly debug and improve internal processes. Thanks to this, we were able to prepare for going public. Integration and Triage Identifying vulnerabilities in a bug bounty program is a key step. We use automatic integration with Slack and Jira to make this process fast and efficient. Slack We use two channels: The main channel for communicating key events in report processing. This includes notifications of new reports, task assignments to engineers, and vulnerability disclosure requests. This channel allows the team to always be aware of critical events. The main channel for communicating key events in report processing. This includes notifications of new reports, task assignments to engineers, and vulnerability disclosure requests. This channel allows the team to always be aware of critical events. An additional channel is for employees involved in the initial analysis and triage of reports. Notifications of non-urgent activities such as report comments and triage details are sent here. An additional channel is for employees involved in the initial analysis and triage of reports. Notifications of non-urgent activities such as report comments and triage details are sent here. Account Matching Account Matching Setting up a mapping between HackerOne and Slack users ensures that important comments and report notes are directly delivered to the responsible parties, minimizing the risk of missing important information. This simplifies communication between the inDrive security team and researchers, facilitating more effective vulnerability remediation. Jira Integration with Jira allows you to create a task only in the right place with a specific set of fields. Using the Jira Automation functionality, we created our own task processing rules to improve our internal vulnerability handling processes, allowing us to efficiently organize this process. Below is an example of this automation: Found By Automation: The system automatically populates the Found By field with the bug bounty value, indicating the origin of the task for analytics. Found By Automation: The system automatically populates the Found By field with the bug bounty value, indicating the origin of the task for analytics. Found By Automation: Task Assignment: Using rules, a task is automatically assigned to an engineer, ensuring even distribution of work. Task Assignment: Using rules, a task is automatically assigned to an engineer, ensuring even distribution of work. Task Assignment: Slack Notifications: When a task is assigned, a notification is sent to Slack that mentions the engineer and provides all the necessary information. Slack Notifications: When a task is assigned, a notification is sent to Slack that mentions the engineer and provides all the necessary information. Slack Notifications: For critical vulnerabilities: For critical vulnerabilities: Messages to a dedicated Slack channel: Notification of a critical vulnerability is sent to a separate channel for immediate response. Messages to a dedicated Slack channel: Notification of a critical vulnerability is sent to a separate channel for immediate response. Messages to a dedicated Slack channel: Sending SMS messages: In addition, SMS notifications are sent to the responsible persons. Sending SMS messages: In addition, SMS notifications are sent to the responsible persons. Sending SMS messages: Fighting Spam With Triggers Triggers in HackerOne are a powerful tool that allows you to automate various actions in response to certain events related to new vulnerability reports. They greatly simplify the work of the security team and help optimize the process of responding to reports. For example, when rebranding the company from inDriver to inDrive, we often encountered reports of problems with social media accounts. We customized the trigger as follows: Trigger condition: If the report contains words from the list: media, social, Facebook, Twitter, Instagram. Trigger condition: If the report contains words from the list: media, social, Facebook, Twitter, Instagram. Trigger condition: Trigger action: When the specified condition is detected, a pop-up window with the following warning text is automatically displayed to the researcher: “Hi, it looks like you are about to report an issue with social media links (Instagram, Twitter, Facebook). Our company is in the process of rebranding and we are aware of this issue. We are temporarily not accepting reports for this issue, so we urge you to properly acknowledge the issue and familiarize yourself with the security policy before proceeding and submitting a report.” Trigger action: When the specified condition is detected, a pop-up window with the following warning text is automatically displayed to the researcher: “Hi, it looks like you are about to report an issue with social media links (Instagram, Twitter, Facebook). Our company is in the process of rebranding and we are aware of this issue. We are temporarily not accepting reports for this issue, so we urge you to properly acknowledge the issue and familiarize yourself with the security policy before proceeding and submitting a report.” Trigger action: “Hi, it looks like you are about to report an issue with social media links (Instagram, Twitter, Facebook). Our company is in the process of rebranding and we are aware of this issue. We are temporarily not accepting reports for this issue, so we urge you to properly acknowledge the issue and familiarize yourself with the security policy before proceeding and submitting a report.” This not only helps to reduce the number of inappropriate reports but also educates researchers, improving the quality of future reports. Campaign and Telegram Channel We understood that over time the activity in the program would decrease. This is a natural process due to the fact that the most obvious vulnerabilities have already been found and eliminated, and attracting the attention of researchers again requires additional efforts. To maintain a high level of engagement and interest in our program, we took a number of measures. One of the key tools was our specialized Telegram channel for bughunters. This channel serves not only as a means of communication but also as a platform for sharing useful information. We actively share information about our application and provide materials that can help researchers find vulnerabilities in our services. This may be technical documentation, descriptions of new features, or architectural changes that may be of interest from a security point of view. Key benefits of our Telegram channel: Key benefits of our Telegram channel: Official updates: Direct and reliable news from the inDrive security team. New Feature Announcements: Information about new services and features that may be of interest to bug bounty enthusiasts. Promotions and Events: Information about special offers and events related to the bug bounty program. Official updates: Direct and reliable news from the inDrive security team. Official updates: New Feature Announcements: Information about new services and features that may be of interest to bug bounty enthusiasts. New Feature Announcements: Promotions and Events: Information about special offers and events related to the bug bounty program. Promotions and Events: More information about the channel can be found by following the link — https://t.me/indrive_bbp. https://t.me/indrive_bbp. https://t.me/indrive_bbp. In addition, to attract both new and experienced bughunters, we regularly launch campaigns on the HackerOne platform. Campaigns allow us to stimulate bughunters’ interest in our program. We also announce all campaign launches via our Telegram channel, which allows us to quickly convey information to the audience and encourage them to participate. For example, below are statistics from one of the campaigns: These measures allow us to keep interest in the bugbounty program at a high level, ensuring a constant flow of fresh ideas and findings, which ultimately contributes to improving the security of our products. Our tips will help you dramatically improve your time to every stage of vulnerability processing — from time to first response to triage to time to bounty. And this, in turn, will increase the trust and satisfaction of the bug hunters participating in your program. In conclusion, our experience in organizing and developing a bug bounty program at inDrive is a vivid example of how hiring external security experts can significantly strengthen a company’s cyber defense. Thanks to our community of white hat hackers, we were not only able to identify and remediate many vulnerabilities but also optimized our internal processes, which increased our efficiency and improved the protection of our systems and data. We thank all participants of our bug bounty program for their invaluable contribution to inDrive’s security and invite new researchers to join our community. Together, we will make the digital world safer!

Strengthening Cybersecurity: Breaking Down inDrive’s Bug Bounty Program

تعزيز الأمن السيبراني: تفكيك برنامج مكافأة الأخطاء الخاص بـ inDrive

Fortalecimiento de la ciberseguridad: análisis del programa Bug Bounty de inDrive

Kyberturvallisuuden vahvistaminen: inDriven Bug Bounty -ohjelman purkaminen

サイバーセキュリティの強化: inDrive のバグ報奨金プログラムの詳細

ការពង្រឹងសុវត្ថិភាពតាមអ៊ីនធឺណិត៖ ការបំបែកកម្មវិធីផ្តល់រង្វាន់នៃកំហុសនៅក្នុងឌីស

Kibernetinio saugumo stiprinimas: „inDrive“ „Bug Bounty“ programos sunaikinimas

Fanamafisana ny fiarovana amin'ny cyber: fandravana ny programa Bug Bounty inDrive

Go Matlafatša Tšhireletšo ya Inthanete: Go thuba Lenaneo la InDrive’s Bug Bounty

සයිබර් ආරක්ෂාව ශක්තිමත් කිරීම: inDrive's Bug Bounty වැඩසටහන බිඳ දැමීම

Posilnenie kybernetickej bezpečnosti: Rozbitie programu Bug Bounty v službe InDrive

Ku Tiyisa Vuhlayiseki bya Inthanete: Ku Hluvukisa Nongonoko wa InDrive’s Bug Bounty

加强网络安全：详解 inDrive 漏洞赏金计划

This article is not related to production development, but it does concern programming. I’ll discuss Dynamic Programming (DP) and how to use previous computation experience effectively. I hope you will find it interesting. Introduction to Dynamic Programming The term Dynamic Programming was first by the famous American mathematician, one of the leading specialists in computer technology, Richard Bellman, back in the 1950s. Dynamic Programming (DP) is a method of solving complex tasks by breaking them down into smaller sub-problems. used The kind of problems that DP can solve must meet two criteria: . Dynamic programming means that the solution for smaller sub-problems can be used to solve the initial one. The optimal substructure is the main characteristic of the “Divide and Conquer” paradigm. 1. Optimal substructure A classic example of implementation is the merge sort algorithm, in which we recursively break the problem down into the simplest sub-problems (size 1 arrays), after which we make calculations based on each one. The results are used to solve the next layer(larger sub-problems) up until the initial layer is achieved. . In computer science, a problem is said to have overlapping subproblems if the problem can be broken down into subproblems which are reused several times. In other words running the same code with the same input data and the same results. A classic example of this problem is the calculation of an N-th element in a Fibonacci sequence, which we will look at below. 2. Overlapping sub-problems You could say that DP is a special case of the use of the Divide and Conquer paradigm, or a more complex version of it. The pattern is well suited for solving tasks involving combinatorics, where a large number of different combinations are calculated, but the N-quantity of elements is frequently monotonous and identical. In the problems of optimal substructure and overlapping sub-problems, we have numerous repeat calculations and operations, if we apply a brute-force approach. DP helps us optimize the solution, and avoid the doubling of computation by using two main approaches: memoization and tabulation: is implemented through recursion. A task is broken down into smaller sub-problems, their results are fed into a memory and combined to solve the original problem through repeated use. 1. Memoization (top-down approach) This approach uses stack memory through recursive method calls Cons: Flexibility toward DP tasks. Pros: is implemented using an iterative method. Sub-problems from the smallest to the initial are calculated in succession, iteratively. 2. Tabulation (bottom-up approach) limited range of application. This approach requires an initial understanding of the entire sequence of sub-problems. But in some problems, this is not feasible. Cons: efficient memory use, as everything is run within a single function. Pros: The theory may sound tedious and incomprehensible  —  let’s look at some examples. Problem: Fibonacci Sequence A classic example of DP is calculating an N-th element in a Fibonacci sequence, where each element is the sum of the two preceding ones, and the first and second elements are equal to 0 and 1. By hypothesis, we initially focus on the nature of the optimal substructure, as, in order to calculate one value, we need to find the preceding one. To calculate the preceding value, we need to find the one that came before that, and so on. The nature of overlapping subtasks is illustrated in the diagram below. For this task, we will be looking at three cases: Straightforward approach: what are the minuses? An optimized solution using memoization An optimized solution using tabulation Straightforward/Brute-force Approach The first thing you might think of is to enter the recursion, sum up the two preceding elements, and give their result. /** 
 * Straightforward(Brute force) approach
 */
fun fibBruteForce(n: Int): Int {
   return when (n) {
       1 -> 0
       2 -> 1
       else -> fibBruteForce(n - 1) + fibBruteForce(n - 2)
    }
} On the screen below, you can see a stack of function calls, to calculate the fifth element in the sequence. Note that the function is called five times, and three times. Functions with one signature, with the same parameters, are launched repeatedly, and do the same thing. When the N number is increased, the tree increases, not linearly, but exponentially, which leads to a colossal duplication of calculations. fib(1) fib(2) Math Analysis: O(2^n), Time Complexity: O(n) -> proportionate to the maximum depth of the recursive tree, as this is the maximum number of elements that can be present in the stack of implicit function calls. Space Complexity: This approach is extremely inefficient. For example, 1,073,741,824 operations are needed to calculate the 30th element. Result: Memoization (Top-Down Approach) In this approach, implementation is not all that different from the foregoing “brute-force” solution, except allocation of memory. Let it be the variable memo, in which we collect the results of the calculations of any completed fib() function in our stack. It should be noted that it would have been sufficient to have an array of integers and refer to it by index, but, for the sake of conceptual clarity, a hash map was created. /**
 * Memoization(Top-down) approach
 */
val memo = HashMap<Int, Int>().apply {
    this[1] = 0
    this[2] = 1
}

fun fibMemo(n: Int): Int {
    if (!memo.containsKey(n)) {
        val result = fibMemo(n - 1) + fibMemo(n - 2)
        memo[n] = result
    }
    return memo[n]!!
} Let’s focus again on the function call stack: The first completed function that writes the result in the memo is the highlighted . It returns control to the highlighted . fib(2) fib(3) The highlighted finds its value after summing up the results of the and calls, enters its solution in the memo and returns control to . fib(3) fib(2) fib(1) fib(4) We have reached the stage for reusing earlier experience  —  when control is returned to , the call awaits its turn in it. in turn, instead of calling ( ), uses the entire finished solution from the memo, and returns it straightaway. fib(4) fib(2) fib(2) fib(1) + fib(0) is calculated and returns control to , which only has to launch . In the last analogy, immediately returns a value from the memo without calculations. fib(4) fib(5) fib(3) fib(3) We can observe a reduction in the number of function calls and calculations. Also, when N is increased, there will be exponentially fewer reductions. Math Analysis: Time Complexity: O(n) Space Complexity: O(n) There is a clear difference in asymptotic complexity. This approach has reduced it to being linear in time, in comparison to the primitive solution, and has not increased it in memory. Result: Tabulation (bottom-up approach) As mentioned above, this approach involves iterative calculation from a smaller to a larger sub-problem. In the case of Fibonacci, the smallest “sub-problems” are the first and second elements in the sequence, 0 and 1, respectively. We are well aware of how the elements relate to each other, which is expressed in the formula: . Because we know the preceding elements, we can easily work out the next one, the one after that, and so on. fib(n) = fib(n-1) + fib(n-2) By summing up the values we are aware of, we can find the next element. We implement this operation cyclically until we find the desired value. /**
 * Tabulation(Bottom-up) approach
fun fibTab(n: Int): Int {
   var element = 0
   var nextElement = 1
   for (i in 2 until n) {
        val newNext = element + nextElement
        element = nextElement
        nextElement = newNext
    }
    return nextElement
} Math Analysis: Time Complexity: O(n) Space Complexity: O(1) This approach is just as effective as memoization in terms of speed, but it uses up a constant amount of memory. Result: Problem: Unique Binary Trees Let’s look at a more complex : we need to find the number of all structurally unique binary trees that can be created from N nodes. problem A is a hierarchical data structure, in which each node has no more than two descendants. As a general rule, the first is called a parent node, and has two children — the left child and the right child. binary tree Let’s assume that we need to find a solution for N = 3. There are 5 structurally unique trees for the three nodes. We can count them in our head, but if the N is increased, the variations would escalate immensely, and visualizing these in our head would be impossible. This task could be ascribed to combinatorics. Let’s work out which combinations can be formed, and how we can find a pattern for their formation. Each tree starts from the top node (Vertex of the Tree). The tree then expands in depth. Each node is the start of a new child tree (subtree), as shown on the screen. The left subtree is colored green, and the right — red. Each one has its own vertex. Let’s look at an example of a task, where N = 6 at the conceptual level. We’ll call our calculation . function numOfUniqueTrees(n: Int) In our example, 6 nodes are given, one of which, according to the principle mentioned earlier, forms the vertex of the tree, and the other 5  —  the remainder. From now on, we interact with the remaining nodes. This can be done in various ways. For example, by using all five nodes to form the left subtree or sending all five to the right subtree. Or by dividing the nodes into two — 2 to the left and 3 to the right (see screen below), we have a limited number of such variants. To achieve the result , we need to consider all variants for distributing our nodes. They are shown in the table: numOfUniqueTrees(6) The table shows 6 different distributions of the nodes. If we find how many unique trees can be generated for each distribution and sum these up, we will achieve our final result. How to find the number of unique trees for distribution? We have two parameters: Left Nodes and Right Nodes (left and right column in the table). . The result will be equal to: numOfUniqueTrees(leftNodes) * numOfUniqueTrees(rightNodes) Why? On the left, we will have X unique trees, and for each, we will be able to put Y unique variations of trees on the right. We multiply these to get the result. So Let's Find Out Variations for the First Distribution (5 Left, 0 right) , as we have no nodes on the right. The result is — the number of unique subtrees on the left with a constant right. numOfUniqueTrees(5) * numOfUniqueTrees(0) numOfUniqueTrees(5) Calculating . numOfUniqueTrees(5) Now we have the smallest sub-problem. We will be operating with it as we did with the larger one. At this stage, the characteristic of the DP tasks is clear  —  optimal substructure, recursive behavior. One node (the green node) is sent to the vertex. We distribute the remaining (four) nodes in a way that is analogous to previous experience (4:0), (3:1), (2:2), (1:3), (0:4). We calculate the first distribution (4:0). It is equal to by earlier analogy. numOfUniqueTrees(4) * numOfUniqueTrees(0) -> numOfUniqueTrees(4) Calculating . If we allocate a node to the vertex, we have 3 remaining. numOfUniqueTrees(4) Distributions (3:0), (2:1), (1:2), (0:3). For 2 nodes there are only two unique binary trees, for 1  —  one. Previously we've already mentioned that there are 5 variations of unique binary trees for three nodes. As a result  —  distributions(3:0), (0:3) are equal to 5, (2:1), (1:2)  —  2. If we sum up 5 + 2 + 2 + 5, we get 14. = 14. numOfUniqueTrees(4) Let’s enter the result of the calculation in the variable memo according to the experience of memoization. Whenever we need to find variations for four nodes, we will not calculate them again, but reuse earlier experience. Let’s return to the calculation (5:0), which is equal to the sum of the distributions (4:0), (3:1), (2:2), (1:3), (0:4). We know that (4:0) = 14. Let’s turn to the memo, (3:1) = 5, (2:2) = 4 (2 variations on the left * 2 on the right), (1:3) = 5, (0:4) = 14. If we sum these up, we get 42, = 42. numOfUniqueTrees(5) Let’s return to the calculation of , which is equal to the sum of the distributions. numOfUniqueTrees(6) (5:0) = 42, (4:1) = 14, (3:2) =10 (5 left * 2 right), (2:3) = 10, (1:4) = 14, (0:5) = 42. If we sum these up, we get 132, . numOfUniqueTrees(5) = 132 Task solved! Result: Let’s note the overlapping sub-problems in the solution where N = 6. In the straightforward solution, would be called 18 times (screen below). With increasing N, repeats of same computation would be far greater. numOfUniqueTrees(3) I highlight that the number of unique trees for (5 left, 0 right) and (0 left, 5 right) will be the same. Only in one case they will be on the left, and in the other on the right. This also works for (4 left, 1 right) and (1 left, 4 right). Memoization, as an approach of dynamic programming, has allowed us to optimize the solution for such a complex task. Implementation class Solution {
fun calculateTees(n: Int, memo:Array<Int?>): Int {
    var treesNum = 0
    if(n < 1) return 0
    if(n == 2) return 2
    if(n == 1) return 1
    if(memo[n]!=null)
        return memo[n]!!

    for (i in 1..n){
        val leftSubTrees = calculateTees( i - 1, memo)
        val rightSubTrees = calculateTees(n - i, memo)

        treesNum += if(leftSubTrees>0 && rightSubTrees>0){
            leftSubTrees*rightSubTrees
        } else
            leftSubTrees+leftSubTrees
    }
    memo[n] = treesNum
    return treesNum
 }
} Conclusion In some cases, solving tasks by means of Dynamic Programming can save a vast amount of time and make the algorithm work with maximum efficiency. Thank you for reading this article to the end. I’d be happy to answer your questions. Posted by Ayat Rakhishev

Understanding Dynamic Programming So You Can Use It Effectively

ডায়নামিক প্রোগ্রামিং বোঝা যাতে আপনি এটি কার্যকরভাবে ব্যবহার করতে পারেন

Dynamische Programmierung verstehen, damit Sie sie effektiv nutzen können

Comprender la programación dinámica para poder utilizarla de forma eficaz

Comprendre la programmation dynamique pour pouvoir l'utiliser efficacement

डायनामिक प्रोग्रामिंग को समझना ताकि आप इसका प्रभावी ढंग से उपयोग कर सकें

動的プログラミングを理解して効果的に使用できるようにする

동적 프로그래밍을 이해하여 효과적으로 사용할 수 있습니다.

Compreendendo a programação dinâmica para que você possa usá-la de maneira eficaz

Понимание динамического программирования для эффективного его использования

Dinamik Programlamayı Anlamak Böylece Etkin Bir Şekilde Kullanabilirsiniz

Hiểu Lập Trình Động Để Bạn Có Thể Sử Dụng Hiệu Quả

了解动态规划以便有效地使用它

Over the last six months, our development team has embraced the "docs-as-code" approach (you can learn more about our journey in this ). Regularly reviewing the documentation created by my colleagues from the Tech Division, I compiled a list of the most common issues found in writing technical documentation. article In the article, I will show you how to fix these issues using the tools of the “docs-as-code” approach. Issue 1. “Docs writing is not under our responsibility” Dealing with documentation on an ad-hoc basis is like shooting yourself in the foot for the entire development team. If the team lacks the capacity, it's a compelling reason to make documentation maintenance more technology-driven and predictable. Fix: Integrate the “docs-as-code” approach to the development of the documentation. This way, you can update the documentation iteratively, alongside the codebase, without the risk of accumulating technical debt. Develop or integrate a space or a platform that can render tech docs and serve as a single source of information. Utilize an integrated development environment (IDE). An IDE enables you to incorporate plugins and create custom scripts for documentation development. is an excellent tool for docs writing, but you may have your favorites among applications. IDEA Install a spell-check plugin to safeguard against typos. Adding the plugin to your IDE is a quick and easy process. Adopt the internal guidelines specially crafted by your company, taking into account insights from the technical writing community (if you have any), to establish a standardized approach for developing documentation within the company. Following these guidelines will streamline the documentation process, saving time in contemplating what and how to write accurately. Automate checks based on the guidelines to significantly reduce or eliminate time for docs review. Template everything possible and agree with the team on standardizing documentation components. I will offer valuable resources that will boost your confidence while working with technical documentation. I believe that these resources are comprehensive enough to equip you for handling tech docs effectively: The " " serves as a comprehensive handbook for developer documentation. It covers everything you need to know about formatting, punctuation, listing, and adding code blocks. This guide is sufficient and has been a valuable reference for developing our internal guidelines, from which we borrowed some best practices. Google Developer Documentation Style Guide “ " is a must-read book for anyone involved in working with developer documentation, whether they are developing, writing, or maintaining it. The book features several renowned and esteemed authors in the field of technical writing. Docs for Developers " " by Anne Gentle, a technical writer, is a practical guide that showcases the documentation culture in OpenStack. Through practical examples, the author explains why documentation should be managed in GitHub and how to implement technological processes for effective documentation. The book also offers valuable insights on writing professional documentation, regardless of whether you are a developer or a technical writer. Docs Like Code I will also mention internal guidelines for writing technical documentation, which should include templates and formatting rules. Such guidelines exist in every company. Typically, they are developed collaboratively with a technical writer-pioneer and dev docs champions and evolve as the documentation culture within the team grows. Issue 2. Writing documentation solo Developing the entire documentation alone and then submitting it for review carries the risk of creating redundant or irrelevant documentation that may not align with the intended purpose. Fix: Always start with an outline and share it with your team lead, product owner, technical writer, or any colleague willing to provide their expert opinion. Write step by step and assign pull requests for review on the same above mentioned colleagues. Collect and work on feedback. Consider the comments. And take it easy on the review tone of voice, sometimes it could be harsh, but it is merely a peculiarity of the review process. Don’t overlook the documentation flow. Below is the general flow adopted in our company, but the features of this flow could depend on a development team as well as the company: Issue 3. “Those who need to understand will understand” From time to time I hear from teams: “I am writing for the development team," "those who need to will understand," "this is how it historically evolved within our team”. But professional jargon and anglicisms require appropriateness and consistency. Excessive use of them may lead to documentation resembling the notes of a mad engineer. For documentation, use the simplest words and structures possible. One of the main principles is writing for scrolling. Documentation can be challenging to write since it is often extensive, but readers rarely go through it from cover to cover. Instead, they tend to scroll or use keyword search. Therefore, the text should be easily understandable when opened from any part. Fix: Check English terms and professional jargon using dictionaries and current norms (or simply Google them). If a word exists in the dictionary, write according to the rules of your language orthography. If the word is not present in the language, write it in the original language, and provide a translation to your language in parentheses. Add the word to the glossary section, and abbreviations to the list of abbreviations and acronyms. This is especially important for "proprietary" abbreviations (no matter how much is mentioned or written about PO, its meaning is still one of the common questions when reading the documentation). Consistency – stick to the chosen writing style and abbreviations throughout the documentation (better for all available documentation in your company). Plan the document navigation carefully. There should be a quick way to find the relevant section without having to read the entire document. Therefore, it is essential to thoughtfully structure the content with clear and concise headings. Internal documentation templates should be developed for simplicity and convenience. Issue 4. Writing documentation simultaneously in multiple places For documentation, having a single source of truth – one space where you can find the necessary information without worrying about its accuracy is crucial. For our technical documentation, an in-house developed platform serves as such a space. Avoiding fragmentation of documentation in different spaces is essential to prevent misleading anyone with outdated information. Fix: Before publishing tech documentation anywhere, ensure that it doesn’t exist somewhere else, if it came up that the company uses several spaces for knowledge sharing. Archive or delete (if you have ownership) outdated technical documentation. If you are concerned about premature deletion (for instance, due to external links to the page), add a callout stating that the page is outdated, and the current documentation location of valid docs, where further updates should be made. If you come across valuable information or insights, add them to the documentation. Do not leave it in Slack or anywhere else, especially in private chats. Knowledge worth sharing! Posted by Anna Goncharova

Common Mistakes in Engineer-Authored Docs and How to Fix Them

ইঞ্জিনিয়ার-লেখক ডক্সে সাধারণ ভুল এবং সেগুলি কীভাবে ঠিক করা যায়

Häufige Fehler in von Ingenieuren verfassten Dokumenten und wie man sie behebt

Errores comunes en los documentos creados por ingenieros y cómo solucionarlos

Erreurs courantes dans les documents rédigés par un ingénieur et comment les corriger

इंजीनियर-लिखित दस्तावेज़ों में सामान्य गलतियाँ और उन्हें कैसे ठीक करें

エンジニアが作成したドキュメントでよくある間違いとその修正方法

엔지니어가 작성한 문서의 일반적인 실수와 해결 방법

Erros comuns em documentos escritos por engenheiros e como corrigi-los

Mühendis Tarafından Yazılmış Dokümanlarda Yaygın Hatalar ve Bunların Nasıl Düzeltileceği

Các lỗi thường gặp trong Tài liệu do kỹ sư tác giả và cách khắc phục chúng

工程师撰写的文档中的常见错误以及如何修复它们

In this article, I will tell you how we automate the user vehicle verification process. I will share with you the components we use, and how we organize the process. At inDrive, we use a great deal of visual content. We are present in a wide range of different regions marked by different mindsets where an abundance of different documentation is used: passports, certificates, and vehicle documents. Apart from that, there are the drivers themselves and their vehicles to deal with. When talking about travel comfort and improved quality of service for our users, safety and eliminating the unexpected are absolute essentials. For example, when the car that pulls up is not the one you booked. You will find out how we at inDrive currently handle regular vehicle verifications. Once that is done, our moderators manually check the before and after photos. Of course, the verification process involves other things as well, but here we will focus only on this aspect. The problem with the current approach is that it is more difficult to increase the number of moderators than it is to scale up the infrastructure. Especially when it comes to dealing with users' personal data. About the Task at Hand Let's put the problem very simply, as though for a child: We have two photos of a car — are they both of the same car? Obviously, anyone could handle this question, but things become much more complicated once we add a comparison criterion. For example, making sure that this is not a screenshot from a cell phone or that the license plate numbers are a perfect match. Globally, this problem can be solved in several ways: Using E2E models and sets of these models. The E2E model implies involving one large model (most likely a neural network) that can answer our questions based on a pair of images, such as “Is it the same vehicle in the photo or not?”, “Do the license plate numbers match up or not?”, etc. The problem with such models is that they require a lot of data to learn from and that they lack an understanding of why the answer is what it is. For instance, if we train a model to answer "yes"/"no" based on a pair of photos, it is no longer possible to figure out the reasons for the answer. So the users will be unable to understand what we want from them and we will have to bring in moderators. This end-to-end approach does not suit us. We want to give the user clues as to why the photo provided doesn’t “fit the bill”: "It's best to take the photo in a well-lit location," "It looks like we don’t see the entire car in the picture," or "The license plate number doesn't match the information provided." Model Quality and Base It’s very important to us that the model does not answer "yes" when there are different vehicles. Let's name this metric the “FPR” (false positive rate) and use it to show the percentage of "yes" responses versus all negative examples (where the vehicles don’t match up). Now, let's introduce another metric — TPR — to measure the ratio of "yes" answers to all affirmative answers. Basically, these two metrics are already enough to describe our task when optimizing the model: To minimize the FPR and ensure that the TPR is not degraded too much. We adopted the model set approach. Therefore, we can add all our ideas to the skeleton of the finished solution (this skeleton will be referred to as the “baseline”). Let's explore what it looks like and break it down into parts. In fact, it consists of several models that independently process two images at the input, and give out the vehicle’s license plate number and its vector, at the output. As a result, based on the details compared, a verification decision is made about the two photos under review. This is the skeleton of the algorithm we use to add in multiple other models, placing them in different nodes of our model. For example, when evaluating the quality of a photo, its clarity, light, and saturation levels. Sometimes, we need to detect attempts at submitting photos that are not genuine. To do this, we add a preprocessor that checks the photo for spoofing attacks. When using such an approach, it’s crucial to have clear product iteration cycles and generate a good test data set. We add a new model to assess these two factors, “Does it solve the problem assigned?” and “How much does it modify the metrics of the previous solution?” Let's now talk about the basic building blocks of the solution. Detection and Segmentation Are All You Need Let's move on to take a look at the terminology. Below, I will explain the meaning of the terms such as "bounding box" and "segmentation mask." A bounding box is a rectangular shape used to enclose a specific object of interest. For example, if we want to identify the cat's face, we would define a bounding box by outlining it in red. It is defined by the coordinates of its lower-left and upper-right points within the image. Segmentation refers to the task of assigning a class label to each individual pixel in an input image. In the context of our discussion, we isolated the cat by segmenting it from the background. In our model, the background of the vehicle is of no interest to us because this provides no relevant information for shaping our target solution. But that doesn't mean we have no ideas about how to improve our models by using backgrounds. To address the challenge of separating vehicles from the background, we will take a model of the YOLO family (You Only Look Once) and train it to segment car images. The problem here is that we have a huge number of photos from users with more than one car in the picture. To overcome this issue, we can employ the following approach: Calculate the distance between the center of mass of the bounding box and the center of the photo. Determine the size of the bounding box. Sort the bounding boxes in ascending order based on the distance from the center and in descending order based on the size of the box. Select the first object in the sorted list. Consequently, we obtain the bounding box that is closest to the center of the picture while being the largest. Great, we've got our first input. The next step is to find the vehicle’s license plate number. In almost all countries, the license plate is located on the front. Those rare cases where vehicle registration plates are located in unusual places are outside the scope of this article. The most common approach to establishing the license plate number is to detect the bounding box and apply OCR to the resulting patch. But as our experiments have shown, OCR is much less effective (and takes longer in some models) if the vehicle’s registration number plate is not parallel to the horizon. This is especially relevant for our data, where we ask that drivers take photos at an angle. The solution we decided on was to segment the number and then smooth the contour line obtained. In our case, the segmentation task was approached similarly to how vehicles are segmented, with the following result: Next, we drew a contour line using the mask and applied ConvexHull to smooth it. This simple algorithm smooths out (straightens) the concavities of our contour line, making it straighter. This can be described as a smaller number of angles in a contour polygon. In an ideal world, this operation would get us a rectangle defined by four points. Once we have gotten the borders aligned, we repeat the same drill with the perspective, so that the registration number is smooth, well-presented, and clearly visible. This approach is especially helpful when a car is photographed very much at an angle where the license plate is hardly visible. What is a perspective correction? I remember from my algebra class how a rotation matrix works. If you take a square in the Cartesian coordinate system and multiply each coordinate by a rotation matrix of 30 degrees, then your square in the new coordinate system will be rotated by 30 degrees. Here, we are dealing with a similar task — let’s take the contour line and move all the points to the new coordinate system. The problem is to find a suitable transformation matrix. All of these algorithms are already well established, so the only thing we have to do is make sure that they are correctly configured for the task at hand. The result was just great. This increased the TPR by nearly 15 percentage points. Next, we apply some lightweight, high-quality OCR software, such as PARSeq architecture. Car Encoder As of now, this is the latest neural network technology for processing vehicle photos. Embeddings are a widely adopted technique in various machine learning fields, including search, recommendations, and data compression. In the context of our task, embeddings are employed to assess the similarity between vehicles. Let's look at an example where I took a picture of my car first from the right-hand side, and then from the left-hand side. Now, I can calculate the embeddings (vectors) for these pictures, and if these vectors are close in space, this indicates that it is the same vehicle. But embeddings provide another useful property that can be used in the product: If your embedding model works well, you can do a search for what is closest from among the embedding samples. For example, to find non-unique vehicles in the system. When training our embeddings model using inDrive data, we took meticulous precautions. We diligently removed any personal data from the photos and ensured the dataset was normalized, encompassing images from all the countries in which we operate and varying quality levels. This approach aims to prevent discrimination against individuals who may not have access to expensive smartphones for capturing high-quality photos. Consequently, obtained a dataset grouped by vehicle brand and make. After running several experiments, we realized that we would have to do without comparing the colors of the vehicles for the time being. When selecting the architecture for our model, we sought a backbone that strikes a balance between performance and computational efficiency. It was crucial to avoid using an excessively large backbone, as it could significantly slow down the baseline running time. After careful consideration, we opted for efficientnet_b2 as our backbone architecture, complemented by the utilization of the Additive Angular Margin Loss for machine learning purposes. The goal of our model is to learn vector representations where vehicles of the same make and model, such as all Audi A4s, are positioned closely together in the vector space. In contrast, Audi A5s would be positioned somewhat farther away from Audi A4s but still closer compared to, for instance, a Toyota Camry. Now, let's delve into a few examples of vehicle comparisons: At the top, we have two identical cars, while at the bottom, we have two different ones. Let's revisit the similarity scores: the top pair has a score of 0.989, while the bottom pair has a score of 0.697. By setting a threshold value of 0.98, we can classify vehicles as identical. However, it's important to note that our model is not yet functioning flawlessly. We have a bias in the concerned factor: The model produces a result of 0.751, whereas we ideally want a value close to zero for different vehicles. The main issue here stems from training our model on datasets primarily focused on vehicle models and brands. Consequently, the model became proficient at distinguishing between different vehicles, but it struggles when evaluating differences within vehicle classes. The second problem we have encountered is that the vehicle may be shown at different angles, which negatively affects the quality of our embeddings due to the limited data set. As the first step, on the client side, we add masks and prompt the driver on how to take a photo of their car. The second step will be to detect different parts of the vehicle for positioning it in space and estimating its rotation. A lot of heuristics can be developed here to choose the correct angle of rotation. And most importantly, these models can be later reused for evaluating the condition of the vehicle. But that's a story for another time. Posted by . Ilya Kaftanov

How We Automated the Verification of Car Photos

আমরা কীভাবে গাড়ির ফটোগুলির যাচাইকরণ স্বয়ংক্রিয় করেছি৷

Wie wir die Überprüfung von Autofotos automatisiert haben

Cómo automatizamos la verificación de fotos de autos

Comment nous avons automatisé la vérification des photos de voitures

हमने कार फ़ोटो का सत्यापन कैसे स्वचालित किया

車の写真の検証を自動化する方法

자동차 사진 확인을 자동화한 방법

Como Automatizamos a Verificação de Fotos de Carros

Araba Fotoğraflarının Doğrulanmasını Nasıl Otomatikleştirdik

Cách chúng tôi tự động xác minh ảnh chụp ô tô

我们如何自动验证汽车照片

of this article, we described how to quickly and easily build an infrastructure for running UI tests on Android using Appium and Selenoid. We are continuing our story to explain how we incorporated the launch of UI tests in iOS into the process. In the first part Scaling with GGR The maximum number of parallel workflows within a host is limited by its resources. Thus, we needed a tool for combining multiple hosts into one cluster. For this, we use the (GGR) from the folks at Aerokube. Based on the description in the documentation, GGR is a load balancer used for creating scalable and highly available Selenium clusters. Go Grid Router The project with the tests runs a query in GGR as part of the process used. It polls the Selenoid parameters specified in its configuration and distributes the load among them based on the platform used, the availability of free flows, and the predefined specific weight of each Selenoid. Deploying GGR and GGR UI is easy: Install . Docker Create a directory for GGR configuration files . mkdir -p /etc/grid-router/quota Create a file . users.htpasswd $ htpasswd -bc /etc/grid-router/users.htpasswd test test-password Create a quotas file where you specify the address of the deployed Selenoid as the host: $ cat /etc/grid-router/quota/test.xml
<qa:browsers xmlns:qa="urn:config.gridrouter.qatools.ru">
<browser name="android" defaultVersion="10.0" defaultPlatform="android">
  <version number="10.0">
    <region name="1">
      <host name="0.0.0.0" port="4444" count="1"/>
    </region>
  </version>
</browser>
</qa:browsers> Run the GGR container: docker run -d \
  --name ggr \
  -v /etc/grid-router/:/etc/grid-router:ro \
  --net host aerokube/ggr:latest-release \
  -listen=:4445 -guests-allowed In the tests project, change the Appium port to the port of the running GGR: val driver = AndroidDriver(URL("http://localhost:4445/wd/hub"), capabilities) Run the GGR UI container: docker run -d \
  --name ggr_ui \
  -p 8888:8888 \
  -v /etc/grid-router/quota:/etc/grid-router/quota:ro \
  aerokube/ggr-ui:latest-release Run the Selenoid UI container where we pass the GGR UI port via : selenoid-uri docker run -d \
  --name selenoid-ui \
  -p 4446:4446 \
  --link selenoid:selenoid \
  aerokube/selenoid-ui:1.10.4 \
  --selenoid-uri "<http://ggr-ui:8888>" Our Selenoid UI should now display the status of all Selenoid clusters connected to GGR. Now, we proceed to the running of tests on iOS We use our own Mac mini farm to run UI tests on iOS. The farm can similarly be assembled from decommissioned but operational MacBooks. Alternatively, they can be . The following needs to be installed on each host: rented Appium (Appium 2.x must be used when one is working with iOS≥16). Xcode. Some early problems We were unable to replicate the structure used in running Android tests because we couldn’t find a way to run iOS simulators in Docker containers. One option that we considered was running , but we ran into doubts about the legality of its use for any purposes unrelated to . So, we decided to go a different route. Docker-OSX OS X Security Research Iteration #1: GGR→Appium We added Appium (port 4723) as a Selenoid host for iOS tests in the previously created GGR config file: <qa:browsers xmlns:qa="urn:config.gridrouter.qatools.ru">
<browser name="android" defaultVersion="10.0" defaultPlatform="android">
  <version number="10.0">
    <region name="1">
      <host name="0.0.0.0" port="4444" count="1"/>
    </region>
  </version>
</browser>
<browser name="iPhone 14" defaultVersion="16.2" defaultPlatform="iOS">
  <version number="16.2">
    <region name="1">
      <host name="0.0.0.0" port="4723" count="1"/>
    </region>
  </version>
</browser>
</qa:browsers> In such a case, the iOS scheme looks like this: The structure used in this iteration is operational. The problem is that, in this case, we can only run tests in one workflow on each Mac mini, which is wasteful. Also, the cluster will not be displayed in the Selenoid UI. Iteration #2: GGR→Selenoid→Appium Selenoid allows you to work . The above problems informed our decision to use Selenoid when running iOS tests as well, though as an executable file: with more than just containers Download Selenoid ( / ). amd64 arm64 Create a configuration file. browsers.json Be sure to specify Appium and startup settings in the configuration file: {
  "iPhone 14": {
    "default": "16.2",
    "versions": {
      "16.2": {
        "image": ["appium", "--log-timestamp", "--log-no-colors", ...]
      }
    }
  }
} Give permission to execute the Selenoid file. In our case, we used . chmod 755 Run Selenoid via the terminal. We used the following parameters: . selenoid -conf ~/browsers.json -disable-docker -capture-driver-logs -service-startup-timeout 4m -session-attempt-timeout 4m -timeout 6m -limit 2 The specified timeouts are necessary because standard timeouts may not be sufficient for downloading the app from the cloud storage and launching the simulator. The parameter was used to set the maximum number of running simulators. This is the reference value to be used by the GGR in the future. The performance of the host is used as a guide for setting the parameter. -limit You can read more about startup settings in the Selenoid . documentation If need be, a PLIST file can be created on each Mac mini to autorun Selenoid in case of a sudden system restart. Now, the process of the cluster looks like this: With this approach, we partially achieve Selenoid UI functionality and the ability to run tests across multiple flows on the same host. The downside is that, on each Mac mini, you have to manually carry out a multitude of routine tasks to create a simulator and link it with Appium by specifying the UUID and port assignment. This can become a problem if you need to upgrade to a new iOS version later. Iteration #3: GGR→Selenoid→Bash→Appium We have a large Mac mini farm that will continue growing as time goes on. With this in mind, we were looking for a way to make scaling easier so that we wouldn’t have to create simulators by hand and then connect them to Appium. With the previous schema in place, Appium and simulators would have had long lifetimes, which could have led to unpredictable consequences. Searching for a solution, we discovered that a bash script can be specified as a host in the Selenoid configuration file: {
  "iPhone 14": {
    "default": "16.2",
    "versions": {
      "16.2": {
        "image": ["~/bin/config/start_appium.sh", "iPhone 14"]
      }
    }
  }
} This is what ours looks like: #!/bin/bash

set -ex

DEVICE_NAME=$1
APPIUM_PORT=$(echo $2 | cut -d '=' -f 2)

function clean() {
  if [ -n "$APPIUM_PID" ]; then
      kill -TERM "$APPIUM_PID"
  fi
  if [ -n "$DEVICE_UDID" ]; then
      xcrun simctl delete $DEVICE_UDID
  fi
}

trap clean SIGINT SIGTERM

# Each simulator has a udid, so to run the same devices in parallel - clone and run
# only clones. You cannot clone a running device. After closing the session, delete the clone.
cloned_device_name="[APPIUM] ${DEVICE_NAME} ($(date +%Y%m%d%H%M%S))"
DEVICE_UDID=$(xcrun simctl clone "$DEVICE_NAME" "$cloned_device_name")

# https://github.com/appium/appium-xcuitest-driver#important-simulator-capabilities
WDA_LOCAL_PORT=$(($APPIUM_PORT+1000))
MJPEG_SERVER_PORT=$(($WDA_LOCAL_PORT+1000))
DEFAULT_CAPABILITIES='"appium:udid":"'$DEVICE_UDID'","appium:automationName":"'XCUITest'","appium:wdaLocalPort":"'$WDA_LOCAL_PORT'","appium:mjpegServerPort":"'$MJPEG_SERVER_PORT'"'

appium --base-path=/wd/hub --port=$APPIUM_PORT --log-timestamp --log-no-colors --allow-insecure=get_server_logs,adb_shell \
       --allow-cors --log-timestamp --log {choose_directory_for_logs} \
       --default-capabilities "{$DEFAULT_CAPABILITIES}" &
APPIUM_PID=$!

wait If the script is used, pay close attention to the stated capabilities and Appium startup settings. These are set up here assuming that Appium 2.x is used for the run ‒ Appium 1.x does not require the vendor to be specified in capabilities, and there is no option of specifying --base-pat. The script solves the problem of simulators running in parallel: When multiple Appiums are directly connected to GGR from one Mac mini, , because you cannot run the same emulator with identical UDIDs. You have to manually duplicate and hardcode the UDID each and every time. (For example, if you need to change the iOS version or the simulator model.) a problem arises with the emulators . It is necessary to run Appium manually every time, and regularly check it for conflicts with ports and simulators. Poor scalability The use of Selenoid makes it possible to simplify this process down to a single script that does not create conflicts between multiple Appium + Simulator pairs within a single host. It launches Appium and kills it when receiving a corresponding signal from Selenoid, and it dynamically clones the simulators at startup and deletes them once the session ends. The process we developed looks like this: Next, we add the Selenoid addresses of each Mac mini to the configuration file of the deployed GGR, merging the Android and iOS structures: Bottom-line summary The assembled infrastructure allows us to run a total of about 500 UI tests per hour across 36 workflows on both platforms. Addition of a new host for Android tests can be fully automated by using the workflow on GitHub Actions, and takes about two minutes. In the very near future, we plan to automate the deployment of the Selenoid cluster on a Mac mini as well. Further down the road, we would like to try out running containers on a Mac mini with Linux to unify all the processes and make it easier to deploy to them without breaking any MacOS usage rules. If you have had any related experience, we'd love for you to share it in the comments. Docker-OSX Posted by . Ivan Grigoriev

How to Run 5000+ Tests on Mobile Devices Everyday; From inDrive's Playbook (Part 2)

কিভাবে প্রতিদিন মোবাইল ডিভাইসে 5000+ পরীক্ষা চালাবেন; ইনড্রাইভের প্লেবুক থেকে (পর্ব 2)

So führen Sie täglich über 5000 Tests auf Mobilgeräten durch; Aus dem Playbook von inDrive (Teil 2)

매일 모바일 장치에서 5000개 이상의 테스트를 실행하는 방법 inDrive의 플레이북(2부)에서

Her Gün Mobil Cihazlarda 5000'den Fazla Test Nasıl Çalıştırılır; inDrive'ın Başucu Kitabı'ndan (Bölüm 2)

Hi all! My name is Taras Egorov; I'm an engineer at inDrive. I'll show you how we set up an infrastructure capable of running more than 5,000 tests per day on iOS and Android devices combined. The secret is simple: we used Selenoid. Preface Last year, our colleagues conducted a study of auto testing, and we took part in a survey as part of the study. We were pleased with the survey's findings, so we decided to write an article to share our experience with you and get some advice in return. We thought it a good idea to divide the material into two parts: the first one focusing on Android and the second on iOS. Let's begin with Android. Running the tests on Android Selenoid is a tool for running and managing browsers and Android emulators in a Docker container. You can read more about this . popular in the documentation To write Appium tests, we use: Kotlin; JUnit 5; Maven. The first run. Setting up Selenoid Create a config file: browsers.json {

  "android": {

    "default": "10.0",

    "versions": {

      "10.0": {

        "image": "browsers/android:10.0",

        "port": "4444",

        "path": "/wd/hub"

      }

    }

  }

} The emulator image is specified in . The guys from have prepared ready-made images of Android emulators. You can check them out or . The images don't differ from each other in any way. image aerokube here here Let’s take the image as an example. The image must be downloaded beforehand: , otherwise the tests will not run: browsers/android:10.0 docker pull browsers/android:10.0 Original error: create container: Error response from daemon: No such image: browsers/android:10.0 The next step is to run Selenoid. We do that directly via , or there’s the option of using . docker Configuration Manager docker run -d \

           -v /var/run/docker.sock:/var/run/docker.sock \

           -v "$(pwd)/selenoid/config/":/etc/selenoid/:ro \

           -p 4444:4444 \

           --name selenoid \

           aerokube/selenoid:1.10.7 You can check to see if Selenoid is working properly by following the link in your browser: http://localhost:4444 You are using Selenoid 1.10.7! Specify the Selenoid address in the Appium tests in the driver: ...
val driver = AndroidDriver(URL("http://localhost:4444/wd/hub"), capabilities)
... Next, specify the link to the build in capabilities: ... 
capabilities.setCapability("appium:app", "https://storage.example.com/builds/app.apk")
... If unable to provide a link, you can specify the path to the build:** ...
capabilities.setCapability("appium:app", "/builds/app.apk")
... Where is the path inside the container where the emulator is being run. For this option to work properly, be sure to specify the in : /builds/app.apk volumes browsers.json {

  "android": {

    "default": "10.0",

    "versions": {

      "10.0": {

        ...

        "volumes": [

          "/home/username/app.apk:/builds/app.apk:ro"

        ]

        ...

      }

    }

  }

} Where is the path to the build on the host platform. /home/username/app.apk That's it, we've almost set up Selenoid, and now we can try running the tests: ./mvnw test But, unfortunately, the tests will not be able to run. Let's look into this and see what's wrong. The second run. Taking a look at the logs and video The first thing to do after a failed startup is to check out the Selenoid logs: docker logs selenoid [INIT] [Loading configuration files...]
[INIT] [Loaded configuration from /etc/selenoid/browsers.json]
[INIT] [Video Dir: /opt/selenoid/video]
[INIT] [Your Docker API version is 1.41]
[INIT] [Timezone: UTC]
[INIT] [Listening on :4444]
[NEW_REQUEST] [unknown] [172.17.0.1]
[NEW_REQUEST_ACCEPTED] [unknown] [172.17.0.1]
[LOCATING_SERVICE] [android] [10.0]
[USING_DOCKER] [android] [10.0]
[CREATING_CONTAINER] [selenoid/android:10.0]
[STARTING_CONTAINER] [selenoid/android:10.0] [75e454341da7fc4b58ba104a5180813bac6cd7c124037a759b6c976e65b168fa]
[CONTAINER_STARTED] [selenoid/android:10.0] [75e454341da7fc4b58ba104a5180813bac6cd7c124037a759b6c976e65b168fa] [0.40s]
[0] [REMOVING_CONTAINER] [75e454341da7fc4b58ba104a5180813bac6cd7c124037a759b6c976e65b168fa]
[0] [CONTAINER_REMOVED] [75e454341da7fc4b58ba104a5180813bac6cd7c124037a759b6c976e65b168fa]
[0] [SERVICE_STARTUP_FAILED] [http://172.17.0.3:4444/wd/hub does not respond in 30s] We see that the status is SERVICE_STARTUP_FAILED. Go to the and look at the status value: documentation SERVICE_STARTUP_FAILED - Failed to start Docker container or driver binary The error doesn’t tell you much, and more information is required. It would be good to take a look at the container logs. Let's do that by enabling logging: docker run -d \

           -p 4444:4444 \

           -v /var/run/docker.sock:/var/run/docker.sock \

           -v "$(pwd)/selenoid/config/":/etc/selenoid/:ro \

           -v  "$(pwd)/selenoid/logs/":/opt/selenoid/logs/ \

           aerokube/selenoid:1.10.7 \

           -log-output-dir /opt/selenoid/logs We also enable logs in the Capabilities section: ...
capabilities.setCapability("enableLog", true)
... Run the tests and review the logs using the browser : http://localhost:4444/logs/ 2023-04-16T13:44:43.909768530Z Waiting X server...
2023-04-16T13:44:44.009494775Z Logging to: /tmp/fluxbox.log
2023-04-16T13:44:44.047587277Z Waiting X server...
2023-04-16T13:44:44.151933325Z Waiting X server...
2023-04-16T13:44:44.262850410Z * daemon not running; starting now at tcp:5037
2023-04-16T13:44:44.457972956Z * daemon started successfully
2023-04-16T13:44:44.458249266Z adb: no devices/emulators found
2023-04-16T13:44:45.463480812Z adb: no devices/emulators found
2023-04-16T13:44:46.471547723Z adb: no devices/emulators found
2023-04-16T13:44:47.476093515Z adb: no devices/emulators found
2023-04-16T13:44:48.481987351Z adb: no devices/emulators found
2023-04-16T13:44:49.486503149Z adb: no devices/emulators found
2023-04-16T13:44:50.492757801Z adb: no devices/emulators found
2023-04-16T13:44:51.499094108Z adb: no devices/emulators found
2023-04-16T13:44:52.505862428Z adb: no devices/emulators found
2023-04-16T13:44:53.513276412Z adb: no devices/emulators found
2023-04-16T13:44:54.520642210Z adb: no devices/emulators found
2023-04-16T13:44:55.527420189Z adb: no devices/emulators found
2023-04-16T13:44:56.534631013Z adb: no devices/emulators found
2023-04-16T13:44:57.316094939Z WARNING. Using fallback path for the emulator registration directory.
2023-04-16T13:44:57.335415397Z checkValid: hw configs not eq
2023-04-16T13:44:57.541959741Z adb: device offline
2023-04-16T13:44:58.547907700Z adb: device offline
2023-04-16T13:44:58.565504866Z emulator: WARNING: System image is writable
2023-04-16T13:44:58.565528396Z emulator: Cold boot: different AVD configuration
2023-04-16T13:44:58.565532576Z Your emulator is out of date, please update by launching Android Studio:
2023-04-16T13:44:58.565536346Z  - Start Android Studio
2023-04-16T13:44:58.565539506Z  - Select menu "Tools > Android > SDK Manager"
2023-04-16T13:44:58.565543076Z  - Click "SDK Tools" tab
2023-04-16T13:44:58.565546216Z  - Check "Android Emulator" checkbox
2023-04-16T13:44:58.565549216Z  - Click "OK"
2023-04-16T13:44:58.565552146Z 
2023-04-16T13:44:59.554451514Z adb: device offline
2023-04-16T13:45:00.560926060Z adb: device offline
2023-04-16T13:45:01.568777440Z adb: device offline
2023-04-16T13:45:12.124226047Z emulator: INFO: boot completed
2023-04-16T13:45:12.124251007Z emulator: INFO: boot time 27848 ms
2023-04-16T13:45:12.124255077Z emulator: Increasing screen off timeout, logcat buffer size to 2M.
2023-04-16T13:45:12.152557294Z emulator: Revoking microphone permissions for Google App. The container logs are not much help here either, because you can't see the Appium logs. Now let's try to enable them. To do this, let's look at the script : entry point.sh ...
if [ -z "$VERBOSE" ]; then
    APPIUM_ARGS="$APPIUM_ARGS --log-level error"
else
    EMULATOR_ARGS="$EMULATOR_ARGS -verbose"
fi
... To enable Appium logs, the parameters and : must be passed to the container: VERBOSE=true APPIUM_ARGS=--log-level debug {

  "android": {

    "default": "10.0",

    "versions": {

      "10.0": {

        ...

        "env": [

          "VERBOSE=true",

          "APPIUM_ARGS=--log-level debug"

        ]

        ...

      }

    }

  }

} To enable Appium to debug logs, you need to pass VERBOSE; in this case, the emulator logs turn on and start filling the "ether"” But we fixed that for future images =) Now it is enough to pass to . APPIUM_ARGS=-log-level debug ...
[HTTP] --> POST /wd/hub/session/c89fa9c2-ca2b-49cd-ab31-590eeccf77d1/element
[HTTP] {"using":"id","value":"authorization_edittext_phone"}
[debug] [W3C (c89fa9c2)] Calling AppiumDriver.findElement() with args: ["id","authorization_edittext_phone","
c89fa9c2-ca2b-49cd-ab31-590eeccf77d1"]
[debug] [BaseDriver] Valid locator strategies for this request: xpath, id, class name, accessibility id, -and
roid uiautomator
[debug] [BaseDriver] Waiting up to 0 ms for condition
[debug] [WD Proxy] Matched '/element' to command name 'findElement'
[debug] [WD Proxy] Proxying [POST /element] to [POST http://127.0.0.1:8200/wd/hub/session/65943f03-3b35-4d3eb221-d6dc7988f935/element] with body: {"strategy":"id","selector":
"authorization_edittext_phone","context":"","multiple":false}
[WD Proxy] Got response with status 404: {"sessionId":"65943f03-3b35-4d3e-b221-d6dc7988f935","value":{"error"
:"no such element","message":"An element could not be located on the page using the given search parameters","stacktrace":"io.appium.uiautomator2.common.exceptions.El
ementNotFoundException: An element could not be located on the page using the given search parameters\n\tat io.appium.uiautomator2.handler.FindElement.safeHandle(Find
Element.java:73)\n\tat io.appium.uiautomator2.handler.request.SafeRequestHandler.handle(SafeRequestHandler.java:41)\n\tat io.appium.uiautomator2.server.AppiumServlet.
handleRequest(AppiumServlet.java:253)\n\tat io.appium.uiautomator2.server.AppiumServlet.handleHttpRequest(AppiumServlet.java:247)\n\tat io.appium.uiautomator2.http.Se
rverHandler.channelRead(ServerHandler.java:68)\n\tat io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:366)\n\tat io
.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:352)\n\tat io.netty.chann...
[debug] [W3C] Matched W3C error code 'no such element' to NoSuchElementError
[debug] [W3C (c89fa9c2)] Encountered internal error running command: NoSuchElementError: An element could not
be located on the page using the given search parameters.
[debug] [W3C (c89fa9c2)]     at AndroidUiautomator2Driver.findElOrEls (/opt/node_modules/appium/node_modules/appium-android-driver/lib/commands/find.js:75:11)
[debug] [W3C (c89fa9c2)]     at process._tickCallback (internal/process/next_tick.js:68:7)
[HTTP] <-- POST /wd/hub/session/c89fa9c2-ca2b-49cd-ab31-590eeccf77d1/element 404 23 ms - 444
... As seen from the logs, Appium cannot find our element. Let's see what is happening on the emulator screen. To do this, we have to run the Selenoid UI: docker run -d \

           --name selenoid-ui \

           -p 8080:8080 \

           --link selenoid:selenoid \

           aerokube/selenoid-ui:1.10.4 \

           --selenoid-uri "http://selenoid:4444" Go to and open the Selenoid UI: http://0.0.0.0:8080 Be sure to enable VNC and video recording in the tests: ...

capabilities.setCapability("enableVNC", true)

capabilities.setCapability("enableVideo", true)

... The Selenoid startup command ends up looking like this: docker run -d \

-v /var/run/docker.sock:/var/run/docker.sock \

-v "(pwd)/selenoid/logs/":/opt/selenoid/logs/ \

-v /opt/selenoid/video/:/opt/selenoid/video/ \

-e OVERRIDE_VIDEO_OUTPUT_DIR="/opt/selenoid/video/" \

-p 4444:4444 \

-name selenoid \

aerokube/selenoid:1.10.7 \

-log-output-dir /opt/selenoid/logs Open the Selenoid UI once the tests are up and running: And here's . a video of it https://www.youtube.com/watch?v=Hm7s5ZjnVYQ&embedable=true We found the cause of the startup error. Great! Let’s move on. The third run. Building an emulator image As it turns out, the images of Selenoid emulators won’t work without Google Play services. To remedy this situation, you must build an emulator image yourself. The guys from aerokube have assembled everything you need for this: and . a repository with photos documentation the repository. Downloading Go to the folder. selenium Run the script and answer the questions. This is what it looks like in our case: ./automate_android.sh Specify Appium version: [1.18.1]

>> 1.18.1

Specify Android image type (possible values: "default", "google_apis", "google_apis_playstore", "android-tv", "android-wear"): [default]

>> google_apis

Specify Application Binary Interface (possible values: "armeabi-v7a", "arm64-v8a", "x86", "x86_64"): [x86]

>> x86

Specify Android version: [8.1]

>> 10.0

Specify device preset name if needed (e.g. "Nexus 4"):

>>

Specify SD card size, Mb: [500]

>>

Specify userdata.img size, Mb: [500]

>>

Are you building a Chrome Mobile image (for mobile web testing): [n]

>> y

Specify Chromedriver version if needed (required for Chrome Mobile):

>> 74.0.3729.6

Specify image tag: [selenoid/chrome-mobile:74.0]

>> android-emulator:10.0

Add Android quick boot snapshot? [y]

>> n When I saw the question Add Android quick boot snapshot?, I thought it was an emulator . But if you look at the , it calls a , which is needed to install APK applications. Basically, it doesn't give us any gain. snapshot code script We already use snapshot emulators , but we'll talk about that in other articles. to speed up container launches Once the image is built, we will be prompted to push it into the registry. Since we don't need that yet, we will kindly decline the offer: Push?  >> n We have put together a build with Google Play services. Remember to change the image parameter in browsers.json, and restart Selenoid. Now let's try rerunning the tests: [INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------ And of the test run. here’s a video https://www.youtube.com/watch?v=w-uzB7hg7g8&t=1s&embedable=true To sum up What we have done: Configured Selenoid to run Android tests. Learned how to check out the logs and videos to troubleshoot. Built our own emulator image with Google Play services. Something else I would like to tell you about: Selenoid timeouts. If your app is large, you might run into problems with timeouts. How we tried making the container run faster. The video shows that the run takes about a minute or so. How we tried running native Android tests written in Espresso on Selenoid. Spoiler alert: this works! Meanwhile, in the next part, we'll tell you how we scaled up the infrastructure and ran tests on iOS.

How to Run 5000+ Tests on Mobile Devices Everyday; From inDrive's Playbook (Part 1)

কিভাবে প্রতিদিন মোবাইল ডিভাইসে 5000+ পরীক্ষা চালাবেন; ইনড্রাইভের প্লেবুক থেকে (পর্ব 1)

So führen Sie täglich über 5000 Tests auf Mobilgeräten durch; Aus dem Playbook von inDrive (Teil 1)

Cómo ejecutar más de 5000 pruebas en dispositivos móviles todos los días; Del libro de jugadas de InDrive (Parte 1)

Comment exécuter plus de 5 000 tests sur des appareils mobiles au quotidien ; Du Playbook d'InDrive (Partie 1)

मोबाइल उपकरणों पर प्रतिदिन 5000+ परीक्षण कैसे करें; इनड्राइव की प्लेबुक से (भाग 1)

モバイルデバイスで毎日 5000 件以上のテストを実行する方法; InDrive のプレイブックより (パート 1)

매일 모바일 장치에서 5000개 이상의 테스트를 실행하는 방법 inDrive의 플레이북(1부)에서

Como executar mais de 5.000 testes em dispositivos móveis todos os dias; Do manual do InDrive (parte 1)

Her Gün Mobil Cihazlarda 5000'den Fazla Test Nasıl Çalıştırılır; inDrive'ın Başucu Kitabı'ndan (Bölüm 1)

Cách chạy hơn 5000 bài kiểm tra trên thiết bị di động mỗi ngày; Từ Playbook của InDrive (Phần 1)

如何每天在移动设备上运行 5000 多个测试；来自 InDrive 的剧本（第 1 部分）

We have a mobile application we need to prepare many scripts for JMeter. We could do it by hand, but it’s better to automate it. In my case, the application can work in two modes — the contractor and the customer. This manual is suitable for any application. Prerequisites: with prepared emulators. Android Studio . Proxyman . JMeter Let’s start. 1. Open up Android Studio. I have two of them (the certificate makes it impossible to record simultaneously into both of them, so we need to alternate): 2. Open up Proxyman. Go to the Certificate tab → Install Certificate on Android → Emulators: 3. Click on Override Emulator and install the certificate to both devices: 4. If all has gone well, we will see traffic from Remote Devices: 5. Working with Android Studio + Proxyman: Install the latest or specific build, and run two devices: View queries in the sniffer. Select the rows we need and save them to the HAR file: 6. Use the . HAR to JMX converter 7. Convert the file to JMX and get a template to work in JMeter. We hope this tutorial will be helpful for you. If you have any other questions, please ask in the comments.

How to Record a Script For a Mobile App for JMeter

Hi everyone! My name is Michil Androsov and this is the second article in my series on the history of , where I offer an inside look at the creation of our unicorn company from the perspective of a simple developer. The first article is available . In it, I talked about how I joined the company, how we expanded the development team, and how we went international. inDrive here This article will cover the middle period of my career at inDrive—from about 2016 to 2020. At the time, the company was beginning to stand on its own two feet and rapidly develop in all kinds of new directions, which I'll discuss in more detail below. The Business After our first successful launches outside of Yakutsk, we were finally starting to recognize the power of our business idea. We began to wonder, "What if we really manage to take over the planet?" After all, living far up north, , you always feel quite separate from the rest of the world. It seems like everything's happening so far away, which actually gives us a pretty unique perspective. And at the time, all of our work with inDrive felt almost like a game to me. deep in Siberia Over this period, the company began to launch extensively. When we'd start operations in a new country, we might launch dozens of cities within a single month. We expanded beyond Russia and launched in Kazakhstan, where—despite a variety of obstacles—we quickly became the country's №1 ride-hailing service. To this day, Kazakhstan remains one of our top markets. When launching in a new city, we adopted a strategy of " ". As our CEO would say, if a city was ready for our service, it should be able to ignite from the smallest of sparks. So, if the grass in one city wasn't dry enough, we wouldn't try to soak it in gasoline. Instead, we'd just move on to the next one. This helped us expand quickly without spending too much money. burning dry grass In fact, a number of cities simply launched on their own. People would hear about this great new service, called inDrive, in a neighboring city. They'd download the app for themselves, and the city would launch without us. There were even a few self-launched cities that took off without any investment on our part. Of course, not all launches were a success. I remember our first back in 2018. We made all the preparations, recruited drivers, and advertised our service. At first, everything seemed to be working out, and our numbers were growing day by day. USA launch We were pleasantly surprised. Was it really that easy to launch in one of the world's largest markets? After all, if you can make it in the US, you can make it anywhere—at least, that's what I thought. But our joy quickly became disappointment: We were faced with a huge industry of fraudsters cashing out stolen credit cards and using them on our service. So, we decided to scrap our American plans and wait for better days—which finally came in 2023. We launched for the second time in the USA, with much better results. This launch is still ongoing. We are currently operating in Miami, and will soon expand to new cities. Looking back, we were being simple and naive. However, we continued to learn from our mistakes and push forward. The Product and Technology We've always believed that our service should be simple and fail-proof, like a . Of course, this has led to accusations that the app isn't "pretty" enough, despite being packed with features. Nokia 3310 In many countries, we had to adapt to local legislation and user needs. That’s why the inDrive app in Almaty might look completely different from the one in New York. Nevertheless, we have been working on making the app "prettier" in all countries over the past years, and I personally think it looks quite modern now. Outside of Russia, inDrive gained a range of new modules, starting with intercity rides and freight delivery, which are now available in countries across the globe. In certain markets, such as Kazakhstan, they are even more popular than our taxi vertical. During this time, our approach to product planning was simple: At the end of every quarter, our CEO would arrive back from his trips to our launch cities, open his laptop, and explain our goals for the upcoming period. Usually, these came from driver and passenger requests. We could have tasks of all different sizes, from introducing card payments to changing the color of the order button. Our CEO played (and continues to play) a crucial role in the development of the company. While he is both an excellent motivator and strategist, he’s also a skilled manager who understands how the product works. Even now, he personally flies to new launch countries, studies the market, conducts customer development, interacts extensively with users, and gathers feedback on the service. On the development side, we quickly realized that our existing code would not be able to support our rapid business growth. Soon, the app would start to lag and decline in quality. So, we decided to rewrite the more "complex" parts of the code. In addition to the PHP monolith, we eventually got ourselves a— —Golang monolith. The entirety of our infrastructure lay on the shoulders of two guys who knew all the inner workings of our enormous machine. If the service ever crashed, they were prepared to turn on their laptops and fix it at any time, day or night. ba-dum-tss We also got our first QA specialist for full-scale testing. This made our lives incredibly easier. Before our QA, we had been spending a lot of time and effort testing new functionality and updates by ourselves, and checking how they interacted with existing versions. Little by little, mobile developers began to join our team, albeit with some difficulty. After all, you needed Apple products to get into iOS development, and those could be difficult to find in Yakutsk. This meant that we struggled to recruit local iOS developers, and our iOS team would sometimes lag behind our Android team when it came to releasing new features. I remember one time in Kazakhstan, when our app was blocked at the government level. I won't get into the details, but to reverse the block, we had to introduce a number of different features, including user instructions, automatic address changes, proxies, and more. In the end, we restored our capabilities in the country and officially reversed the block after a few years. I remember writing to the CTO of a large CIS news site that had also been blocked in Kazakhstan, and asking how he had managed to keep business going. Many of our features were developed through a series of trials and errors—or stumbled upon by chance—although they might seem completely obvious in hindsight. Take our call-free ride-hailing system, for example. If you haven't read the , I'll quickly summarize it here. first article Previously, when an inDrive passenger would create their order, a driver would see their request in the orders feed and call them right away. And this wouldn't be just one driver either; these orders were being sent to anyone nearby. Of course, this led to situations where multiple drivers would see an order and try to call the passenger at once. Typically, the first person to contact the passenger would get the order. Here's where the problem came in: Drivers would click on a ride without reading the order details, and then all try to call the passenger at the same time. So, we created something called a "buffer." When drivers press the order button, there's a short delay, which gives us time to collect all potential offers. This way, drivers don't have to rush, and they have time to read the order details in full. Then, based on the drivers' ratings, the system selects which of them will be able to call the passenger first. This was a significant improvement to our old version. Although the call-free system is now used by practically every ride-hailing app, we actually came up with ours by chance. In 2016, we launched in Yekaterinburg and introduced the "Guardians," who were specially selected drivers that could accept orders that typical drivers couldn't. We would send them special push notifications about exclusive orders. However, we soon realized that these push notifications weren't working very well because they were easy to miss. And that's when we remembered one of our existing features, called "personal orders," which allowed the passenger to simply select the closest driver on the map and send the order straight to them. We decided to use this feature when sending orders to our "Guardians." It took off immediately and worked so well that we then decided to expand it to all drivers. Of course, the personal orders feature might seem obvious now, but we discovered it through a series of trials and errors. The Team Up until 2019, our team was fully made up of Yakutsk locals. At the time, we wanted to help our homeland grow — and the local people along with it. inDrive had always held a strong mission and values. These values resonated with each employee, and we strived to uphold them. This was a period of powerful drive and energy. Every day, I would wake up in a good mood, knowing that my friends and good coffee were waiting for me in the office. That and plenty of interesting work, of course. inDrive was known for being a social company. Our team was young and carefree, which meant we worked hard and played hard. Every year, we'd take a company trip abroad, whether to Egypt, Thailand, Kazakhstan, or somewhere else entirely. Imagine an entire plane of colleagues escaping the –50-degree Celsius weather in Yakutsk to visit sunny +35-degree Thailand! It was great at the time, but unfortunately, these big company trips aren't possible anymore with a workforce of several thousand employees. By 2019, we hit a hiring roadblock. Business was booming, and any professionals in Yakutsk capable of handling the tasks and workload were already working for us. So, we decided to open a development office in Moscow. As the head of the iOS team, I was charged with opening the Moscow branch. We had a lot of flexibility during this time, and employees were free to contribute to the company in any way they saw fit, as long as it benefited the business. I entered a new phase in my life. I moved to Moscow and started the process of opening the new office, from choosing a business center to installing special lights with the company logo. Now that a few years have passed, I can look back at that time fondly. But back then, I would often think: "Why did I do this to myself? Why'd I take on all this renovation work?" Our main problems had to do with the company in charge of the renovation. At one point, they were so behind schedule that I even had to help them install the electrical wiring in the workspaces. I remember one specific evening, when we stayed late to assemble furniture. I could see that my colleagues were tired and depressed, so to lighten the mood, I asked " " At the time (and to this day), Belorusskaya was one of the most expensive areas in Moscow, like Times Square in New York. It was also home to a number of impressive IT offices. Of course, we just laughed and got back to work. Why the long faces? Cheer up! Next year, we're opening an office on Belorusskaya! By the end of 2019, we had our first developers at the Moscow office. Sometimes, it would seem like they were from another planet. During their interviews, they'd say things like, "We work in sprints. I finished all my tasks, then came here" (and it'd only be Thursday afternoon). Or they'd say, "We work three days from home and two days from the office." That was something completely new for me. inDrive was entirely office-based at the time, and everyone was expected to contribute fully. We weren't working with any kind of Kanbans, scrums, story points, or sprints. Conclusion We entered 2020 with a lot of optimism. Our new development office in Moscow had opened, and we were working with a great team. I was living in the capital, business was growing, and investments were on their way! When the company received investments, we would conduct a cashout, meaning employees could sell a small portion of their stock options for real money. Everything seemed to be going our way, like we were living in a movie. Unfortunately, though, this is the point in my story where things get a little darker, like in the Harry Potter movies. Suddenly, we were faced with a huge challenge. In 2020, the world was shut down by the coronavirus. inDrive closed their offices and we started to work from home—something we had always been firmly against. Life took on new rules and we had to quickly find our footing. We developed new processes, took our first online calls, and sent laptops home to new employees. Then, in mid-2020, I became the CTO of inDrive. It was a surprise even for myself. I was placed in charge of 50+ developers, 4 distributed teams, and the two offices in Moscow and Yakutsk. Of course, there were plenty of challenges, which I'll discuss in more detail in my next article. My joke about our office on Belorusskaya quickly became reality. At the end of 2020, we opened an office in one of the best business centers in Moscow, right on Belorusskaya Square, alongside other cool IT companies. P.S.

Building a Unicorn: The inDrive Tech Journey from Local Startup to Global Phenomenon 

ইউনিকর্ন তৈরি করা: স্থানীয় স্টার্টআপ থেকে গ্লোবাল ফেনোমেনন পর্যন্ত ইনড্রাইভ টেক জার্নি

Aufbau eines Einhorns: Die inDrive-Tech-Reise vom lokalen Startup zum globalen Phänomen

Construyendo un unicornio: el viaje tecnológico de inDrive desde una startup local hasta un fenómeno global

Construire une licorne : le parcours technologique d'inDrive, de la startup locale au phénomène mondial

यूनिकॉर्न का निर्माण: स्थानीय स्टार्टअप से वैश्विक घटना तक इनड्राइव टेक यात्रा

ユニコーンの構築: 地元のスタートアップから世界的現象への inDrive テクノロジーの旅

유니콘 만들기: 로컬 스타트업에서 글로벌 현상까지의 inDrive 기술 여정

Construindo um unicórnio: a jornada tecnológica do inDrive, de uma startup local a um fenômeno global

Создание единорога: технологическое путешествие inDrive от локального стартапа к глобальному феномену

Bir Tekboynuz Yaratmak: Yerel Startup'tan Küresel Fenomen'e inDrive Teknoloji Yolculuğu

Xây dựng kỳ lân: Hành trình công nghệ inDrive từ khởi nghiệp địa phương đến hiện tượng toàn cầu

打造独角兽：从本地初创企业到全球现象的 inDrive 技术之旅

Welcome to our brand new series - The HackerNoon Company of the Week, where we feature the top tech brands from our tech company database, making their evergreen mark on the internet. This unique HackerNoon database ranks S&P 500 companies and top startups of the year alike.This week, we present our business blogging partner__inDrive__ (former inDriver, short for “Independent Drivers“) - a ride-hailing service with one big edge from its competitors: the fare for the trip is set by the passengers themselves! Who doesn't like autonomy and self sovereignty ✊ Wanna be part of HackerNoon’s evergreen tech company database? Request Your Tech Company Page on HackerNoon! Meet inDrive: #FunFact Did you know that inDrive started as a small community of independent drivers in Yakutsk? According to the inDrive's ex-CTO: "As far as cab services were concerned, it was difficult and expensive to get a ride in Yakutsk before inDrive made its appearance on the scene. Things worked the old-fashioned way, and you had to call first and book a vehicle via the dispatcher and then wait a long time for the driver to arrive.In the winter of 2012, several smart guys created a Vkontakte group called Community of Independent Drivers of Yakutsk. In it, you could indicate that you needed to go from point A to point B and leave your phone number. Then a caring driver who just happened to be headed that way might call you to arrange a ride." From a small community of independent drivers to one of the top ride hailing services known globally, inDrive has come a long way! inDrive’s Featured Business Stories on HackerNoon inDrive.tech has shared some amazing content via the HackerNoon Business Blogging Program, and has generated 3 months 9 days 6 hours and 36 minutes of reading time! Here are our top 3 favorite stories by InDrive: Understanding Dynamic Programming So You Can Use It Effectively
How We Automated the Verification of Car Photos
How to Run 5000+ Tests on Mobile Devices Everyday; From inDrive's Playbook That's all this week, hackers!Stay Creative, Stay Iconic.The__HackerNoon Team__ Welcome to our brand new series - The HackerNoon Company of the Week, where we feature the top tech brands from our tech company database , making their evergreen mark on the internet. This unique HackerNoon database ranks S&P 500 companies and top startups of the year alike. This week, we present our business blogging partner__ inDrive __ (former inDriver, short for “Independent Drivers“) - a ride-hailing service with one big edge from its competitors: the fare for the trip is set by the passengers themselves! Who doesn't like autonomy and self sovereignty ✊ tech company database tech company database inDrive Wanna be part of HackerNoon’s evergreen tech company database? Request Your Tech Company Page on HackerNoon! Wanna be part of HackerNoon’s evergreen tech company database? Request Your Tech Company Page on HackerNoon ! Request Your Tech Company Page on HackerNoon Meet inDrive: #FunFact Did you know that inDrive started as a small community of independent drivers in Yakutsk? According to the inDrive's ex-CTO : inDrive's ex-CTO inDrive's ex-CTO "As far as cab services were concerned, it was difficult and expensive to get a ride in Yakutsk before inDrive made its appearance on the scene. Things worked the old-fashioned way, and you had to call first and book a vehicle via the dispatcher and then wait a long time for the driver to arrive.In the winter of 2012, several smart guys created a Vkontakte group called Community of Independent Drivers of Yakutsk. In it, you could indicate that you needed to go from point A to point B and leave your phone number. Then a caring driver who just happened to be headed that way might call you to arrange a ride." "As far as cab services were concerned, it was difficult and expensive to get a ride in Yakutsk before inDrive made its appearance on the scene. Things worked the old-fashioned way, and you had to call first and book a vehicle via the dispatcher and then wait a long time for the driver to arrive.In the winter of 2012, several smart guys created a Vkontakte group called Community of Independent Drivers of Yakutsk. In it, you could indicate that you needed to go from point A to point B and leave your phone number. Then a caring driver who just happened to be headed that way might call you to arrange a ride." "As far as cab services were concerned, it was difficult and expensive to get a ride in Yakutsk before inDrive made its appearance on the scene. Things worked the old-fashioned way, and you had to call first and book a vehicle via the dispatcher and then wait a long time for the driver to arrive. In the winter of 2012, several smart guys created a Vkontakte group called Community of Independent Drivers of Yakutsk. In it, you could indicate that you needed to go from point A to point B and leave your phone number. Then a caring driver who just happened to be headed that way might call you to arrange a ride." From a small community of independent drivers to one of the top ride hailing services known globally, inDrive has come a long way! inDrive’s Featured Business Stories on HackerNoon inDrive.tech has shared some amazing content via the HackerNoon Business Blogging Program , and has generated 3 months 9 days 6 hours and 36 minutes of reading time! Here are our top 3 favorite stories by InDrive: inDrive.tech HackerNoon Business Blogging Program Understanding Dynamic Programming So You Can Use It Effectively How We Automated the Verification of Car Photos How to Run 5000+ Tests on Mobile Devices Everyday; From inDrive's Playbook Understanding Dynamic Programming So You Can Use It Effectively Understanding Dynamic Programming So You Can Use It Effectively How We Automated the Verification of Car Photos How We Automated the Verification of Car Photos How to Run 5000+ Tests on Mobile Devices Everyday; From inDrive's Playbook How to Run 5000+ Tests on Mobile Devices Everyday; From inDrive's Playbook That's all this week, hackers! Stay Creative, Stay Iconic. The__ HackerNoon Team __ HackerNoon Team

Meet inDrive: The HackerNoon Company of the Week

মিট ইনড্রাইভ: সপ্তাহের হ্যাকারনুন কোম্পানি

Lernen Sie inDrive kennen: Das HackerNoon-Unternehmen der Woche

Conozca inDrive: la empresa de la semana de HackerNoon

Rencontrez inDrive : l'entreprise HackerNoon de la semaine

इनड्राइव से मिलिए: इस सप्ताह की हैकरनून कंपनी

inDrive のご紹介: 今週の HackerNoon 企業

inDrive에서 만나보세요: 금주의 HackerNoon 회사

Conheça inDrive: a empresa HackerNoon da semana

Встречайте inDrive: компания недели HackerNoon

inDrive'da Tanışın: Haftanın HackerNoon Şirketi

Gặp gỡ inDrive: Công ty HackerNoon của tuần

结识 inDrive：本周 HackerNoon 公司

How are you, hacker?
🪐 has got you covered with fresh content from our trending stories of the day! Set email preference . Want to know what's trending right now?: The Techbeat by HackerNoon here Octopus Network Unveils Omnity, Pioneering a Fully Decentralized Cross-Chain World By [ 2 Min read ]
Octopus Network announces the upcoming launch of Omnity, a groundbreaking product designed to enhance cross-chain transactions @pressreleases Read More. LanceDB: Your Trusted Steed in the Duel Against Data Complexity By [ 8 Min read ]
There are many ways to build on the foundation offered in this tutorial to create performant, scalable and future-proofed ML/AI architectures. @minio Read More. Understanding Vulnerabilities and Safeguards in Blockchain Oracles By [ 2 Min read ]
This Blockchain Oracle Summit break down offers key insights into the vulnerabilities and safeguards in the realm of blockchain oracles. @oraclesummit Read More. What Are Wallet Drainers? How to Protect Yourself From Them! By [ 7 Min read ]
Learn about wallet drainers, how to detect and respond to compromises, and the role of Wallet Rescue by Hackless in safeguarding the crypto assets. @hackless Read More. The Principles to Keep In Mind When Building a Modern Datalake for Your AI Infrastructure By [ 5 Min read ]
The AI game is about performance at scale, and this requires the right foundation. Here's how to be smart when building a modern datalake. @minio Read More. A Step-By-Step Guide For Implementing OKRs In Your Scaling Startup By [ 6 Min read ]
An OKR has two parts: the objective, your goal, and the key results, what success looks like. @vvmrk Read More. Headset Reality Wars: Meta @ $1B Quarterly VR Revenue & Apple Vision Pro Sells 200k Units in 10 Days By [ 2 Min read ]
Reality Labs, the VR subsidiary of Meta, passed $1B in Q4 VR Revenue, according to Meta’s earning call. Apple Vision Pro sold 200k units in its first ten days. @david Read More. Building a Unicorn: The inDrive Tech Journey from Local Startup to Global Phenomenon By [ 10 Min read ]
Michil Androsov shares an insider's perspective on how a simple idea from the depths of Siberia grew into a global ride-hailing phenomenon. @michil Read More. 10 Tips to Take Your ChatGPT Prompts to the Next Level By [ 11 Min read ]
Maximize your ChatGPT experience with 10 expert tips for crafting precise prompts and queries, enhancing interaction quality. @morganmsk Read More. Cybersecurity Tips: Vulnerability Scanners Essentials By [ 6 Min read ]
Cybersecurity Vulnerability Scanners Essentials, OWASP ZAP, Burp Suite, Nessus, Sn1per, Metasploit, SQLMap. @shad0wpuppet Read More. Improving Testing Algorithms: Mathematical Approaches in Software Testing By [ 7 Min read ]
Test design, Code coverage, MC/DC, Boolean algebra, Pairwise testing, Combinatorial testing, Orthogonal arrays, System states @shad0wpuppet Read More. Cybersecurity Essentials: Practical Web App Security Testing Tips for QA Engineers By [ 10 Min read ]
Cybersecurity for QA - web app security: XSS, Header Injections, CSRF, RCE, Command Injection, Web Parameter Tampering, CORS, Content Security Policy (CSP) @shad0wpuppet Read More. Why Open Source Language Models Are True “Open AI” By [ 4 Min read ]
H2O.ai's Danube is the latest in a series of open-source language models. @FrederikBussler Read More. Tech Bro, Crypto Bro, and NFT Bro - The Evolution of Identity in the Digital World By [ 2 Min read ]
Let's find out who crypto, tech, and NFT bros are, where they came from, and why they are subjected to ridicule online. Hold tight, our journey will be awesome! @cryptobro Read More. Dione Protocol Shines as Crypto Winter Thaws: Paving the Way for Green Energy Revolution By [ 7 Min read ]
As the cream rises to the top, Dione Protocol is poised to shine, leveraging this revitalized landscape to drive growth and deliver on the promise of blockchain @dioneprotocol Read More. I Built a Platform to Help Users Practice Programming Challenges Guided by AI By [ 6 Min read ]
Walking  through the process of building a platform leveraging AI to help users practice for interviews; integrating feedback from the first few live user tests @emmanuels Read More. The Top 13 Trends in 2024: AI Predictions By [ 12 Min read ]
Read our VIRAL 70k-view Medium article "AI predictions: Top 13 AI trends for 2024". A comprehensive guide to the future of artificial intelligence. @pragmaticcoders Read More. Tech Company News Data Dump on HuggingFace: 7M Most Cited Posts About 3k Most Valued Tech Companies By [ 2 Min read ]
HackerNoon curated and open sourced the internet's most cited 7M+ tech company news articles and blog posts about the 3k+ most valuable tech companies. @david Read More. Timeboxing: How I Plan My Day (as a Product Manager) By [ 2 Min read ]
Timeboxing changed the way I plan my days (and even months). I get more of the right 'stuff' done with this method than I ever did before. @alexdebecker Read More. Tech-Gate.org Racks Up Over 1000 DMCA Copyright Infringements By [ 5 Min read ]
Tech-Gate.org, apparent operated and published under the name Bourbiza Mohamed, has been under fire for this rampant copyright infringement site. 🧑‍💻 What happened in your world this week? It's been said that , , . Feeling stuck? We got you covered ⬇️⬇️⬇️ We hope you enjoy this worth of free reading material. Feel free to forward this email to a nerdy friend who'll love you for it.
See you on Planet Internet! With love,
The HackerNoon Team ✌️ @technologynews Read More. writing can help consolidate technical knowledge establish credibility and contribute to emerging community standards ANSWER THESE GREATEST INTERVIEW QUESTIONS OF ALL TIME

The TechBeat: Octopus Network Unveils Omnity, Pioneering a Fully Decentralized Cross-Chain World (2/10/2024)

Stories, News & Mentions about INDRIVETECH

Indrivetech’s Stories on HackerNoon

Indrivetech's News & Mentions