Algorithmic tasks in the frontend. Yandex examples and competition
Yesterday a new Yandex Blitz started - this time the competition will be of interest to interface developers. Holders of places from first to fifth, we will offer to get us in a simplified scheme: one section of the interview instead of four. Thus, Blitz remains the fastest way to get into Yandex.
The tasks of the competition are again close to the combat production tasks - you will need not only the skills of the front-end, but also the knowledge of the algorithms. Register here to take part in the qualifying round.
Blitz is a good reason to talk about the history of algorithmic problems arising in the industrial front end, and how they differ from the competition ones.
Algorithm-rich tasks in the development of interfaces in Yandex always arose. I can recall examples from 2005-2006. One of these tasks was the system of working with abstract events. It was necessary to make a kernel that would allow to hang handlers (set by a function) on arbitrary events (specified by a string), after which - to call a specific event and remove the binding of the handler. An additional complication was that the three basic operations listed were to be performed as quickly as possible. There is even a section in one of the old reports about it .
Another interesting challenge was the location of thumbnails in the search results for Yandex.Kartinok. It was necessary to make the alignment of the flow of rectangular objects of the same height and different widths along the right edge. In the general case, this task has no solution, therefore it was allowed to change the original size of the picture (reduce and crop), but so that the loss of information does not exceed some given reasonable threshold in percent.
There were also tasks related to the development of a Yandex template engine known for the keywords XJST and BEMTHML. The main difficulty was to make it fairly fast, while maintaining the desired semantic expressiveness. Details about this can be viewed in numerous reports. Here are some of the first reports with details: events.yandex.ru/lib/talks/43 andevents.yandex.ru/lib/talks/329 , there are many others.
All kinds of real-time processing systems, such as scrolling and dragging with a mouse, are also often made to reflect. One has to invent various algorithmic tricks so that the interface — at least subjectively for the user — looks fast if real actions are performed objectively for a long time.
For example, in one of the first versions of Yandex. Mail, you could drag almost all key elements onto each other: letters to folders, tags to letters, letters to tags, and even folders to letters. In the process, while the user “clamped” an object in his hand and drove them around the screen, it was necessary to highlight those elements to which he could “reset”. The naive implementation "in the forehead" was inhibited to the extreme.
Tasks inside Yandex, as a rule, are solved in a command mode. The man is not left to himself, as in the competition. He can get help from colleagues and must dock his decision with the interests of other participants in the process.
It may happen that you wrote a quick version, but most of your colleagues consider the code to be unreasonably difficult to understand, develop, and future support. In such cases, it is necessary to seek compromises. Most often, team interaction is arranged as the sequential addition of something to a solution or as a simultaneous pair programming process. We almost never do the same thing in parallel, then to compare and choose the best.
Another important difference is that the real code that we write exists and continues to be maintained for a long time. This is not a “made-and-forgotten” process, so long as the tests pass. It is important to remember that your code can continue to live - not only executed, but also edited - for many years after writing.
You can easily find on the Internet sites with tasks purely on JavaScript. This is essentially the same sport programming, just in a specific language. In addition, there is the format "code in the dark", when the layout is made up without viewing the result, blindly, you see only the code. Competitions like ours are not particularly common, because, due to the specifics of interface development, it is very difficult to select good tasks and make automatic checks for them. Yandex has historically developed a strong school of automatic front-end testing, including using the comparison of screenshots from real browsers. On the basis of these developments, we sought to make checks on the tasks in the competition. For us, this is also an experiment, but we are confident that it will work out, and we are already preparing to develop the topic further.
The tasks of the competition are again close to the combat production tasks - you will need not only the skills of the front-end, but also the knowledge of the algorithms. Register here to take part in the qualifying round.
Blitz is a good reason to talk about the history of algorithmic problems arising in the industrial front end, and how they differ from the competition ones.
About tasks
Algorithm-rich tasks in the development of interfaces in Yandex always arose. I can recall examples from 2005-2006. One of these tasks was the system of working with abstract events. It was necessary to make a kernel that would allow to hang handlers (set by a function) on arbitrary events (specified by a string), after which - to call a specific event and remove the binding of the handler. An additional complication was that the three basic operations listed were to be performed as quickly as possible. There is even a section in one of the old reports about it .
Another interesting challenge was the location of thumbnails in the search results for Yandex.Kartinok. It was necessary to make the alignment of the flow of rectangular objects of the same height and different widths along the right edge. In the general case, this task has no solution, therefore it was allowed to change the original size of the picture (reduce and crop), but so that the loss of information does not exceed some given reasonable threshold in percent.
There were also tasks related to the development of a Yandex template engine known for the keywords XJST and BEMTHML. The main difficulty was to make it fairly fast, while maintaining the desired semantic expressiveness. Details about this can be viewed in numerous reports. Here are some of the first reports with details: events.yandex.ru/lib/talks/43 andevents.yandex.ru/lib/talks/329 , there are many others.
All kinds of real-time processing systems, such as scrolling and dragging with a mouse, are also often made to reflect. One has to invent various algorithmic tricks so that the interface — at least subjectively for the user — looks fast if real actions are performed objectively for a long time.
For example, in one of the first versions of Yandex. Mail, you could drag almost all key elements onto each other: letters to folders, tags to letters, letters to tags, and even folders to letters. In the process, while the user “clamped” an object in his hand and drove them around the screen, it was necessary to highlight those elements to which he could “reset”. The naive implementation "in the forehead" was inhibited to the extreme.
Differences of real tasks from competitive ones
Tasks inside Yandex, as a rule, are solved in a command mode. The man is not left to himself, as in the competition. He can get help from colleagues and must dock his decision with the interests of other participants in the process.
It may happen that you wrote a quick version, but most of your colleagues consider the code to be unreasonably difficult to understand, develop, and future support. In such cases, it is necessary to seek compromises. Most often, team interaction is arranged as the sequential addition of something to a solution or as a simultaneous pair programming process. We almost never do the same thing in parallel, then to compare and choose the best.
Another important difference is that the real code that we write exists and continues to be maintained for a long time. This is not a “made-and-forgotten” process, so long as the tests pass. It is important to remember that your code can continue to live - not only executed, but also edited - for many years after writing.
About other frontend competitions
You can easily find on the Internet sites with tasks purely on JavaScript. This is essentially the same sport programming, just in a specific language. In addition, there is the format "code in the dark", when the layout is made up without viewing the result, blindly, you see only the code. Competitions like ours are not particularly common, because, due to the specifics of interface development, it is very difficult to select good tasks and make automatic checks for them. Yandex has historically developed a strong school of automatic front-end testing, including using the comparison of screenshots from real browsers. On the basis of these developments, we sought to make checks on the tasks in the competition. For us, this is also an experiment, but we are confident that it will work out, and we are already preparing to develop the topic further.