App for CarPrice Inspectors
Our inspectors who inspect cars when they are accepted for auction do not have to choose the conditions - they work in the rain, in the snow, and in the summer heat. They do not just carefully examine the car, but also fill hundreds of check-list items, take dozens or even hundreds of photos, record video. And all this without a pack of papers, a camera and a camera, but with just one smartphone and our special application. Recently, we even patented our car inspection system. Under the cut - the story with the details.
When a person comes to us who wants to sell his car, you need to conduct a detailed inspection of the car, fix the equipment, damage and hidden defects, as well as check its legal purity. This is done by inspectors -specially trained car specialists at CarPrice branches: by checking lists of several hundred points, they carefully inspect the car, take photographs of any defects found, shoot video so that you can listen to the sound of the engine, enter all the necessary credentials. Since the car needs to be photographed from all possible sides and angles, sometimes unexpected, the first generation iPad Mini was originally purchased for inspectors: it was relatively inexpensive, with a good camera and a fairly large screen. On the tablets, the inspectors went to the web interface of our internal service, where all the data was entered.
But inspectors do not always work in comfortable conditions of heated offices with Wi-Fi, cars are often inspected in open areas, outside the city, in the seller’s territory, in remote regions, where the usual cellular communications may be unstable. Web applications love greenhouse conditions, and the inspector needs mobility, and it was inconvenient to fill in a large amount of photos and videos through such an interface. And since even Wi-Fi is not always caught outside the office, employees had to do double work, running from cars to the office in order to dump materials first to the workstation and then upload them to the web service.
')
We decided to develop a full-fledged mobile application that will make the inspection process strictly formalized, universal for all employees and predictable in time. Well, it will speed up the inspection procedure so that the owner of the car does not wait for a long time, impatiently looking at his watch.
The application was originally supposed to be a sort of "Swiss knife" so that the inspector could inspect the car and enter all the information about it without leaving the application. According to our idea, during the inspection we had to:
Having studied the knowledge base of humanity, we stopped on a reactive approach with RxJava. We had to create subscriptions for changes in data and dependencies, reliably link the dynamically generated visual components of the checklist and data whose format was strictly formalized.
So, in our case, the basic MVVM architectural pattern was the best choice, because it provides two-way interaction of models with visual elements, and any change in the visual part is instantly fixed and updated in the database. To increase the flexibility of development, they decided to use Dependency Injection, which has been popular lately, turning a blind eye to some loss of transparency and an increase in the input threshold. As a result, we managed to build a clearly synchronized system of interaction with the visual part, a system for background processing of large amounts of data, as well as a data exchange mechanism between the application and the backend.
The mobile application directly interacts with only two nodes:
2.5 months passed from the start of development to the launch of the first version. Initially, the backend was written by our team, and the alpha version of the client itself was created by a company specializing in mobile development. Unfortunately, the task turned out to be too difficult to entrust it to strangers, and we assembled our team, which was able to make a full-fledged application for inspecting and setting cars for sale.
And now more about some aspects of the device and the application.
We decided to abandon the tablet in favor of smartphones. There were several reasons for this. Firstly, cameras are usually worse in tablets than in expensive smartphones, and the quality of the shooting was a key factor, as they are greeted by clothes - potential buyers evaluate the lot by photos. And secondly, the tablets are much larger in size, which is why inspectors often dropped and broke them. When the inspector inspects the car, then with him:
All this should be at hand, tools often hang on the wrists on the eyelets. In addition, the inspector can be gloves, thread or insulated, suitable for working with capacitive screens. In order to use all this, fill out checklists and not drop a noticeably worthwhile device, you need to have one or two hands more.
And since we decided to switch to smartphones, then the interface of the future application needed to be adapted for screens of the appropriate size. We chose the device for our inspectors according to the following criteria:
We studied the ratings and reviews of smartphones on sites like www.techradar.com and www.cnet.com , analyzed the parameters and bought several different models. Then they began to meticulously test their capabilities in photo and video. Checked the work of autofocus in poor light during the precipitation. Conducted blind tests on the results of the shooting. Studied the size of the resulting photos and videos, the level of noise on the matrix. They checked the reliability: they dropped, froze, poured water and generally scoffed in every possible way to choose the really strong one.
The entire obstacle course was only Sony Z3. By the way, more vandal-resistant covers were produced for him than for other smartphones we considered.
Given the amount of work with photos and videos, it was immediately clear that the functionality of a standard camera would not be enough. At a minimum, its interface should be harmoniously embedded in our application, in other words, write a new one. Therefore, we developed our solution based on the Camera module from the Android SDK.
The inspector photographs strictly according to the check-list. Since not all photographers are born, the application displays hints on how to hold the smartphone vertically or horizontally. Without leaving the camera interface, the inspector can go on to shoot the next part of the car.
We also implemented a hint system when shooting certain details. For example, when an inspector photographs a VIN, he additionally displays the text so that the inspector can immediately see if everything is in order. Also on the photo are blurred car numbers, stickers are displayed, and so on.
When we started shooting video of the engine and exhaust system, we were faced with the fact that at the hardware level, the Sony Z3 firmware did not provide for a change of resolution. The videos were written only in the standard resolution, written in the Sony SDK - Full HD, 60 frames / sec. And although we used our own codec, the one-minute file took 100-150 MB. Naturally, this affected the speed of transmission over the network, especially 3G. And the SDK did not allow the hardware to access the camera module. I had to suffer, tried several different post-processing solutions, including decoding on the fly before sending, selected the bitrate and frame rate. Postprocessing took little time, but “ate” a lot of batteries and made the application heavier. We struggled unsuccessfully with this until Sony did not heed user pleas and released an update in which you can change the resolution of the video.
A formalized description of the state of the vehicle - the task is not so simple. Indeed, through our auction, not only cars can be sold, but also motorcycles, and ATVs, and mopeds, and even trucks. It is obvious that each class has its own technical features. Therefore, we have formed three types of checklists: structural elements and aggregates of the vehicle, equipment and damage. These checklists are the cornerstone of the application, everything was started for them.
In order not to write a separate layout for each car model, the interface should be formed on the fly based on the checklist, depending on the type of vehicle being inspected. To do this, we have made configuration files, the current version of which is loaded at the same time when the client starts. On the basis of these files, the check list interface for a specific vehicle is dynamically generated. We also wrote a set of business logic, which, when going to a certain stage of filling in information about a car, takes a data structure from a configuration file and, on its basis, dynamically generates sets of fields. The data structure of the configuration files contains not only the set, number and types of fields to fill in, but also the dependencies between these fields. That is, when the inspector fills out a checklist, when changing a parameter, additional fields may appear.
For example, if you select “vehicle” in the “Vehicle type” field, a field will appear for selecting a power steering device that will not appear for a motorcycle. Naturally, when changing the top level of dependency - for example, we filled out a meeting about the VAZ-2109, and suddenly decided to choose Harley-Davidson - the interface is rebuilt.
This gives a huge room for maneuver. For example, to change the order of the checklist or add additional options, you do not even need to change the frontend. So, you do not need to rebuild the application, put it into the market and mess around with other operations. Realm ORM is used to store configuration files; it is one of the fastest ORMs in terms of read speed.
The application is rather unusual authorization. In addition to the fact that the inspector can enter it only under his account, he can do it only during his working time and only under his branch.
Also, partners who want to use our application, we pass the installation APK-file, because on Google Play the application is distributed only for our corporate domain.
The backend consists of several logical parts.
Configuration file generator: a service that creates files, on the basis of which a user interface is generated when the application starts.
Avtochek: this is a separate service, in which from the inspector's application the data about the car and the owner are transmitted via an HTTP request (VIN, CTS, PTS, registration number, owner's full name, and so on). “Avtochek” automatically checks these data in various services, of which there are about 15 of them today (Autocode, traffic police, AVInfo, FMS, FNP, etc.), takes screenshots of each check and saves information on the number of fines, their amounts, restrictions on registration actions , according to the VIN-number of PTS, participation of the car in the accident, mileage at the time of the last MOT Just a minute later, the inspector receives a full report on the car. If the machine is "problematic", the inspector may refuse to further inspection and say goodbye to the seller.
Stars: this is an automatic car assessment service in four categories (Body, Salon, Technical condition, Associated factors). For each of them, rating rules from 1 to 5 stars are set. All categories, except "Related Factors", are calculated based on the number and degree of damage. Related factors are evaluated by parameters such as the number of owners of TCP, whether the vehicle is under warranty, whether there is a service book, what mileage and so on. In total, the car can earn no more than 20 stars (5 in each category). Most of the lots have from 10 to 15 stars, it is extremely rare to get “killed” cars with 9 stars and less on the auction. Over 15 - this is almost perfect condition, such cars are included in the top auction rating.
All background tasks and processes — checks, loading and sending data — are implemented as separate, asynchronously processed threads. Thanks to the Observer pattern that underlies the RX components, all this data is collected in one place. As all the tasks are completed, we can always get the result of the work of any background thread.
To work with the network, we use the classic combination Retrofit 2 + OkHttp 3. From one inspection, 40-300 photos are obtained, and even video, totaling about 300 MB, so we have to transfer very large amounts of data over the network. As you understand, the older and tacky the car, the more photos you get, and for the vast majority of cars 70-150 shots are enough. If the machine is completely old and “dead”, then it is examined in a simplified way, and the damage is simply not recorded.
We chose Amazon AWS for media storage. Since the backend must know about new files in time, simultaneously with uploading to the storage, notifications with metadata for each file are sent to the server.
As already mentioned, the Internet during the inspection is not always available. And fast Internet is almost a luxury. Therefore, the application has offline and online operation. While there is no connection, the inspector can calmly collect data, fill out forms, take photos and videos. Information is accumulated in the database on the smartphone. And as soon as the network appears, a gradual sending of data through the thread pool begins, asynchronously into several threads, regardless of what proportion of checklists is already filled. And when the inspector completes the inspection and presses the “Submit” button, most of the information is already in the repository. To manage the sequence of tasks and control their execution, we have developed a set of JobQuery tools.
Long gone are the days when the car could be repaired with the help of only one jack and a set of keys with screwdrivers. Modern cars are crammed with electronics, including OBD system sensors - this is an on-board diagnostics tire. And it was a sin for us not to use this tool. But in the open access there were very few technical materials on OBD. There are only a few small open-source projects that allow you to establish a basic interaction with different OBD-modules. Initially, we took one of these projects as a basis, expanding its capabilities along the way, although there were plenty of difficulties.
There is no universal data exchange protocol by which specific errors (for example, airbags) can be diagnosed, each manufacturer has its own protocol. Additional protocols with metadata that differ from different brands are also used. Even the same error code from different manufacturers may have different values. With such a mess, you need to have information about the basic set of error codes for each manufacturer, and depending on what car you came to, compare the codes, model and brand.
But when we began to interview our customers - auto dealers - if they need to decipher the error codes, it turned out that they already know the key codes by heart, and depending on their content, they can themselves assume what problems the car has. Therefore, for the time being we have stopped at the fact that we will provide only error codes without decoding. By the way, if anyone knows a powerful library for working with obd2 - we will be grateful for the information in the comments!
Mobile application greatly facilitated life inspectors. So much so that instead of 4 hours, on average, it takes 1–1.5 hours to inspect one car. Thanks to the development of checklists and a hint system, inspectors began to detect much more defects, that is, dealers get more accurate descriptions of the condition of cars. Finally, inspectors are no longer tied to Wi-Fi and can travel for inspection literally anywhere in the world.
From the point of view of the development of the application architecture, we are currently working on the standardization of damage guides in order to quickly add new vehicle inspection instructions without issuing a new application release.
We also succumbed to fashion and experimenting with the use of a neural network for post-processing processing in order to identify insufficient quality photos taken by inspectors. Of course, the quality of the neural network will not improve, but at least it will be able to retroactively show the inspector where he did not follow the focusing so that the next time he could be more attentive. You see, soon artificial intelligence will begin to teach inspectors the art of composition and work with light.
And the third direction to improve the application: we form a knowledge base on the features and disadvantages of specific models of specific manufacturers. For example, in this model, the VIN on the body is located there, in the other model with such an engine, valves start knocking after a certain mileage, in the third model the trunk lid is constantly rusting, and so on. Then the inspector, inspecting a car for which there is such a set of data, will receive hints at different stages on what to look for.
And we are switching to Huawei smartphones. Sony Z3 is no longer available, and however reliable it may be, sooner or later everything breaks down. So after a new iteration of reading reviews and barbaric tests, we chose the Huawei P10 Lite.
When a person comes to us who wants to sell his car, you need to conduct a detailed inspection of the car, fix the equipment, damage and hidden defects, as well as check its legal purity. This is done by inspectors -
But inspectors do not always work in comfortable conditions of heated offices with Wi-Fi, cars are often inspected in open areas, outside the city, in the seller’s territory, in remote regions, where the usual cellular communications may be unstable. Web applications love greenhouse conditions, and the inspector needs mobility, and it was inconvenient to fill in a large amount of photos and videos through such an interface. And since even Wi-Fi is not always caught outside the office, employees had to do double work, running from cars to the office in order to dump materials first to the workstation and then upload them to the web service.
')
We decided to develop a full-fledged mobile application that will make the inspection process strictly formalized, universal for all employees and predictable in time. Well, it will speed up the inspection procedure so that the owner of the car does not wait for a long time, impatiently looking at his watch.
Choosing an architectural pattern
The application was originally supposed to be a sort of "Swiss knife" so that the inspector could inspect the car and enter all the information about it without leaving the application. According to our idea, during the inspection we had to:
- A number of resource-intensive processes are simultaneously performed, such as: working with files, capturing photos and videos, processing media data (photos, video, audio), interacting with the data storage, network and external services.
- Generate numerous data, combined into complex entities. These entities we planned to store locally and edit on the fly, they should be available online and offline.
Having studied the knowledge base of humanity, we stopped on a reactive approach with RxJava. We had to create subscriptions for changes in data and dependencies, reliably link the dynamically generated visual components of the checklist and data whose format was strictly formalized.
So, in our case, the basic MVVM architectural pattern was the best choice, because it provides two-way interaction of models with visual elements, and any change in the visual part is instantly fixed and updated in the database. To increase the flexibility of development, they decided to use Dependency Injection, which has been popular lately, turning a blind eye to some loss of transparency and an increase in the input threshold. As a result, we managed to build a clearly synchronized system of interaction with the visual part, a system for background processing of large amounts of data, as well as a data exchange mechanism between the application and the backend.
The mobile application directly interacts with only two nodes:
- with the server part through its own API. It is based on the principles of REST. The server part is highly branched, it accesses additional services (for legal verification, for resizing images and videos, for processing photos using a neural network, and so on), receives data from them and gives them to clients;
- with AmazonAWS to upload media files and then synchronize via API methods.
2.5 months passed from the start of development to the launch of the first version. Initially, the backend was written by our team, and the alpha version of the client itself was created by a company specializing in mobile development. Unfortunately, the task turned out to be too difficult to entrust it to strangers, and we assembled our team, which was able to make a full-fledged application for inspecting and setting cars for sale.
And now more about some aspects of the device and the application.
Smartphone selection
We decided to abandon the tablet in favor of smartphones. There were several reasons for this. Firstly, cameras are usually worse in tablets than in expensive smartphones, and the quality of the shooting was a key factor, as they are greeted by clothes - potential buyers evaluate the lot by photos. And secondly, the tablets are much larger in size, which is why inspectors often dropped and broke them. When the inspector inspects the car, then with him:
- Torch.
- Napkins for wiping contaminated parts.
- Thickness gauge for measuring paint coating.
- OBD scanner
All this should be at hand, tools often hang on the wrists on the eyelets. In addition, the inspector can be gloves, thread or insulated, suitable for working with capacitive screens. In order to use all this, fill out checklists and not drop a noticeably worthwhile device, you need to have one or two hands more.
And since we decided to switch to smartphones, then the interface of the future application needed to be adapted for screens of the appropriate size. We chose the device for our inspectors according to the following criteria:
- The most important thing is the quality of the shooting.
- Battery.
- Protective covers.
- Work in the temperature range from +30 to -50.
- So that the SDK is supported and developed.
- That there was moisture protection, because sometimes cars come in the rain.
We studied the ratings and reviews of smartphones on sites like www.techradar.com and www.cnet.com , analyzed the parameters and bought several different models. Then they began to meticulously test their capabilities in photo and video. Checked the work of autofocus in poor light during the precipitation. Conducted blind tests on the results of the shooting. Studied the size of the resulting photos and videos, the level of noise on the matrix. They checked the reliability: they dropped, froze, poured water and generally scoffed in every possible way to choose the really strong one.
The entire obstacle course was only Sony Z3. By the way, more vandal-resistant covers were produced for him than for other smartphones we considered.
Camera
Given the amount of work with photos and videos, it was immediately clear that the functionality of a standard camera would not be enough. At a minimum, its interface should be harmoniously embedded in our application, in other words, write a new one. Therefore, we developed our solution based on the Camera module from the Android SDK.
The inspector photographs strictly according to the check-list. Since not all photographers are born, the application displays hints on how to hold the smartphone vertically or horizontally. Without leaving the camera interface, the inspector can go on to shoot the next part of the car.
We also implemented a hint system when shooting certain details. For example, when an inspector photographs a VIN, he additionally displays the text so that the inspector can immediately see if everything is in order. Also on the photo are blurred car numbers, stickers are displayed, and so on.
When we started shooting video of the engine and exhaust system, we were faced with the fact that at the hardware level, the Sony Z3 firmware did not provide for a change of resolution. The videos were written only in the standard resolution, written in the Sony SDK - Full HD, 60 frames / sec. And although we used our own codec, the one-minute file took 100-150 MB. Naturally, this affected the speed of transmission over the network, especially 3G. And the SDK did not allow the hardware to access the camera module. I had to suffer, tried several different post-processing solutions, including decoding on the fly before sending, selected the bitrate and frame rate. Postprocessing took little time, but “ate” a lot of batteries and made the application heavier. We struggled unsuccessfully with this until Sony did not heed user pleas and released an update in which you can change the resolution of the video.
Interface and Security
A formalized description of the state of the vehicle - the task is not so simple. Indeed, through our auction, not only cars can be sold, but also motorcycles, and ATVs, and mopeds, and even trucks. It is obvious that each class has its own technical features. Therefore, we have formed three types of checklists: structural elements and aggregates of the vehicle, equipment and damage. These checklists are the cornerstone of the application, everything was started for them.
In order not to write a separate layout for each car model, the interface should be formed on the fly based on the checklist, depending on the type of vehicle being inspected. To do this, we have made configuration files, the current version of which is loaded at the same time when the client starts. On the basis of these files, the check list interface for a specific vehicle is dynamically generated. We also wrote a set of business logic, which, when going to a certain stage of filling in information about a car, takes a data structure from a configuration file and, on its basis, dynamically generates sets of fields. The data structure of the configuration files contains not only the set, number and types of fields to fill in, but also the dependencies between these fields. That is, when the inspector fills out a checklist, when changing a parameter, additional fields may appear.
For example, if you select “vehicle” in the “Vehicle type” field, a field will appear for selecting a power steering device that will not appear for a motorcycle. Naturally, when changing the top level of dependency - for example, we filled out a meeting about the VAZ-2109, and suddenly decided to choose Harley-Davidson - the interface is rebuilt.
This gives a huge room for maneuver. For example, to change the order of the checklist or add additional options, you do not even need to change the frontend. So, you do not need to rebuild the application, put it into the market and mess around with other operations. Realm ORM is used to store configuration files; it is one of the fastest ORMs in terms of read speed.
The application is rather unusual authorization. In addition to the fact that the inspector can enter it only under his account, he can do it only during his working time and only under his branch.
Also, partners who want to use our application, we pass the installation APK-file, because on Google Play the application is distributed only for our corporate domain.
Backend
The backend consists of several logical parts.
Configuration file generator: a service that creates files, on the basis of which a user interface is generated when the application starts.
Avtochek: this is a separate service, in which from the inspector's application the data about the car and the owner are transmitted via an HTTP request (VIN, CTS, PTS, registration number, owner's full name, and so on). “Avtochek” automatically checks these data in various services, of which there are about 15 of them today (Autocode, traffic police, AVInfo, FMS, FNP, etc.), takes screenshots of each check and saves information on the number of fines, their amounts, restrictions on registration actions , according to the VIN-number of PTS, participation of the car in the accident, mileage at the time of the last MOT Just a minute later, the inspector receives a full report on the car. If the machine is "problematic", the inspector may refuse to further inspection and say goodbye to the seller.
Stars: this is an automatic car assessment service in four categories (Body, Salon, Technical condition, Associated factors). For each of them, rating rules from 1 to 5 stars are set. All categories, except "Related Factors", are calculated based on the number and degree of damage. Related factors are evaluated by parameters such as the number of owners of TCP, whether the vehicle is under warranty, whether there is a service book, what mileage and so on. In total, the car can earn no more than 20 stars (5 in each category). Most of the lots have from 10 to 15 stars, it is extremely rare to get “killed” cars with 9 stars and less on the auction. Over 15 - this is almost perfect condition, such cars are included in the top auction rating.
All background tasks and processes — checks, loading and sending data — are implemented as separate, asynchronously processed threads. Thanks to the Observer pattern that underlies the RX components, all this data is collected in one place. As all the tasks are completed, we can always get the result of the work of any background thread.
To work with the network, we use the classic combination Retrofit 2 + OkHttp 3. From one inspection, 40-300 photos are obtained, and even video, totaling about 300 MB, so we have to transfer very large amounts of data over the network. As you understand, the older and tacky the car, the more photos you get, and for the vast majority of cars 70-150 shots are enough. If the machine is completely old and “dead”, then it is examined in a simplified way, and the damage is simply not recorded.
We chose Amazon AWS for media storage. Since the backend must know about new files in time, simultaneously with uploading to the storage, notifications with metadata for each file are sent to the server.
As already mentioned, the Internet during the inspection is not always available. And fast Internet is almost a luxury. Therefore, the application has offline and online operation. While there is no connection, the inspector can calmly collect data, fill out forms, take photos and videos. Information is accumulated in the database on the smartphone. And as soon as the network appears, a gradual sending of data through the thread pool begins, asynchronously into several threads, regardless of what proportion of checklists is already filled. And when the inspector completes the inspection and presses the “Submit” button, most of the information is already in the repository. To manage the sequence of tasks and control their execution, we have developed a set of JobQuery tools.
OBD (On-Board Diagnostic)
Long gone are the days when the car could be repaired with the help of only one jack and a set of keys with screwdrivers. Modern cars are crammed with electronics, including OBD system sensors - this is an on-board diagnostics tire. And it was a sin for us not to use this tool. But in the open access there were very few technical materials on OBD. There are only a few small open-source projects that allow you to establish a basic interaction with different OBD-modules. Initially, we took one of these projects as a basis, expanding its capabilities along the way, although there were plenty of difficulties.
There is no universal data exchange protocol by which specific errors (for example, airbags) can be diagnosed, each manufacturer has its own protocol. Additional protocols with metadata that differ from different brands are also used. Even the same error code from different manufacturers may have different values. With such a mess, you need to have information about the basic set of error codes for each manufacturer, and depending on what car you came to, compare the codes, model and brand.
But when we began to interview our customers - auto dealers - if they need to decipher the error codes, it turned out that they already know the key codes by heart, and depending on their content, they can themselves assume what problems the car has. Therefore, for the time being we have stopped at the fact that we will provide only error codes without decoding. By the way, if anyone knows a powerful library for working with obd2 - we will be grateful for the information in the comments!
What is the result?
Mobile application greatly facilitated life inspectors. So much so that instead of 4 hours, on average, it takes 1–1.5 hours to inspect one car. Thanks to the development of checklists and a hint system, inspectors began to detect much more defects, that is, dealers get more accurate descriptions of the condition of cars. Finally, inspectors are no longer tied to Wi-Fi and can travel for inspection literally anywhere in the world.
Future plans
From the point of view of the development of the application architecture, we are currently working on the standardization of damage guides in order to quickly add new vehicle inspection instructions without issuing a new application release.
We also succumbed to fashion and experimenting with the use of a neural network for post-processing processing in order to identify insufficient quality photos taken by inspectors. Of course, the quality of the neural network will not improve, but at least it will be able to retroactively show the inspector where he did not follow the focusing so that the next time he could be more attentive. You see, soon artificial intelligence will begin to teach inspectors the art of composition and work with light.
And the third direction to improve the application: we form a knowledge base on the features and disadvantages of specific models of specific manufacturers. For example, in this model, the VIN on the body is located there, in the other model with such an engine, valves start knocking after a certain mileage, in the third model the trunk lid is constantly rusting, and so on. Then the inspector, inspecting a car for which there is such a set of data, will receive hints at different stages on what to look for.
And we are switching to Huawei smartphones. Sony Z3 is no longer available, and however reliable it may be, sooner or later everything breaks down. So after a new iteration of reading reviews and barbaric tests, we chose the Huawei P10 Lite.
Source: https://habr.com/ru/post/342936/
All Articles