Interface development school: parsing tasks for Minsk and a new set in Moscow / Yandex Blog / Sudo Null IT News

. Still, semantics - it is about understanding the composition of your page and the purpose of each block (the majority did it here), as well as about the use of pre- and / or post-processors (few did it here, although this was also in points - less and scss were most often connected) .

Working slider . In the assignment, we wrote that JS cannot be used. Here the ability to solve problems was tested - the slider could be made using a bunchand . All magic happens at the selector level # button-N: checked ~ .slider-inner .slider-slides. When we click on one of the input checkboxes, it goes into checked state. We can use this and assign the desired translate to our container with slides: transform: translate (-33%). See the slider implementation here .

Drop down lists . It all came down toand a similar selector: .accordion-item input: checked ~ .accordion-item__content. See the implementation here .

Presence of states: hover,: active and: focu *. A very important point. Comfort depended on him during interaction with the interface. The user should always receive feedback on their actions. This item was checked throughout the interaction with the questionnaire. If I clicked the “Call Me” button and visually nothing happened (even though the request was sent) - this is bad, because then I will click it again and again. As a result, ten requests will be sent and I will be called back ten times. Do not forget that there is no mouse on mobile devices - which means there should not be a hover. And one more thing that did not concern those who complied with the point about semantics. If your control is not an interactive element, then when you hover over it, the cursor will remain standard. It looks very untidy, even if you prescribed a response to hover. Do not underestimate cursor: pointer.

Animation . It is important that everything that happens with the reaction elements is smooth. There is nothing instant in life, so the presence of transitions on hover and active was enough to make the interface more pleasant. Well, those who animated the slider and lists are generally well done.

Using the latest technology . Many used flex, but no one completed the task using grid. An item counted if flex was used correctly. If somewhere, because of these same flexes, the layout was parting - alas, you did not receive additional points.

Validation of the form . All that was required was to add the required attribute to each input form. We added points to those who validated the email field as email.

Styling the file upload button. We expected to see a bunch of the form:and select the file . Further it was required to hide input and to style label. There is another common way - to make a transparent input and put it on top of the button. But not all browsers allow styling., and such a decision cannot be called fully cross-browser. And it is semantically more correct to make a label.

Cross-browser compatibility . We checked that everything is fine, in the last two versions of modern browsers (without IE, the participants were lucky), as well as in Safari on iPhones and in Chrome on androids.

We, on the contrary, scored points if someone used JS or Bootstrap: both of them made the whole task meaningless. Moreover, participants with Bootstrap not only received a minus, but also lost a lot of points for semantics and implemented elements.

Those who marked up their site somewhere on the Internet did not get a particular advantage - but the inspectors were very happy when they did not have to download the repositories and run them locally on their computer. So this served as a plus in karma.

The first task was very useful primarily for the student. Those whom we have not accepted now have a compiled summary - you can proudly attach it to all the responses or put it on your gh-pages.

Task 2: Transport Route

The author of the task is Denis Balyko, head of the search interface group.

Condition

You have a starry sky map. It shows the name of each star, as well as the distance from it to other stars in light seconds. Implement the solution function, which should take three arguments: an object in which the keys are the names of the stars, and the values are the distances to the stars (in space one-way traffic), as well as the names of the starting and ending points of the path - start and finish, respectively. The function should return the shortest distance from the star start to the star finish and the path along which it is necessary to go.

Function Signature:
const solution = function(graph, start, finish)  {
    // Ваше решение
} 
Sample input:
const graph = {
  start: { A: 50, B: 20 },
  A: { C: 40, D: 20 },
  B: { A: 90, D: 90 },
  C: { D: 160, finish: 50 },
  D: { finish: 20 },
  finish: {}
};
const start = 'start';
const finish = 'finish'; 
Sample output:
{
    distance: 90,
    path: ['start', 'A', 'D', 'finish']
} 
Note: the solution framework is in the src / folder, put your solution in solution.js.

Verification of the second task was the most automated and objective. Most of the guys guessed that it was necessary to implement Dijkstra's algorithm. Those who found his description and implemented the algorithm on JS are great. However, when checking the assignment, we met a lot of work with the same errors. We searched the Internet for fragments of code and found an article from where the participants wrote off the algorithm. It is funny that many people copied the code from the article along with the author’s comments. Such work received a low score. We do not prohibit the use of any sources, but we want the person to delve into what he writes.

Criteria

The main points were awarded for the tests. Sometimes it was evident that the guys were mistaking the repository by renaming folders, and the tests fell simply because they could not find the files they needed. This year we tried to help such guys and returned everything to their place for them. But next year we plan to switch to a contest system, and this will not be forgiven.

There were also “human”, manual criteria. For example - the presence of a single code style. No one reduced points for using tabs instead of spaces or vice versa. It’s another matter if you alternate single quotes with double quotes according to one known rule, and put semicolons separately.

Separately, the clarity and readability of the solution was taken into account. At all conferences around the world they say that the programmer’s work consists of 80% reading other people's code. Even schoolchildren go through a code review - with their curators and each other. So this criterion had significant weight. There were works in which there were no variables longer than one character - please do not do so. The comments of the participants were very pleased - with the exception of those that were identical to the comments of Stella Chang.

The last criterion is the availability of autotests. They were added by only a few people, but for everyone this has become a huge plus in karma.

The right decision:

const solution = function(graph, START, FINISH)  {
    // Всё не бесплатно в этом мире
    const costs = Object.assign({[FINISH]: Infinity}, graph[START]);
    // Первая волна родительских нод
    const parents = { [FINISH]: null };
    Object.keys(graph[START]).reduce((acc, child) => (acc[child] = START) && acc, parents)
    const visited = [];
    let node;
    // Ищем «дешёвого» родителя, отмечаем пройденные
    do {
        node = lowestCostNode(costs, visited);
        let children = graph[node];
        for (let n in children) {
            let newCost = costs[node] + children[n];
            // Ещё не оценена или нашёлся более дешёвый переход
            if (!costs[n] || costs[n] > newCost) {
                costs[n] = newCost;
                parents[n] = node;
            }
        }
        visited.push(node);
    } while (node)
    return {
        distance: costs[FINISH],
        path: optimalPath(parents)
    };
    // Возврат назад по самым «дешёвым» родителям
    function optimalPath(parents) {
        let optimalPath = [FINISH];
        let parent = parents[FINISH];
        while (parent && parent !== START) {
            optimalPath.push(parent);
            parent = parents[parent];
        }
        optimalPath.push(START);
        return optimalPath.reverse();
    }
    // Минимальная стоимость из текущей ноды среди непросмотренных
    function lowestCostNode(costs, visited) {
        return Object.keys(costs).reduce((lowest, node) => {
            if (lowest === null || costs[node] < costs[lowest]) {
                if (!visited.includes(node)) {
                    lowest = node;
                }
            }
            return lowest;
        }, null);
    };
};

Task 3: Event Calendar

It was prepared by interface developers Sergey Kazakov and Alexander Podskrebkin.

Condition

Напишите мини-календарь для отображения расписания. Можно взять любое расписание, которое вам понравится. Например, расписание фронтенд-конференций в 2019 году.

Календарь должен выглядеть, как список. Других требований к дизайну нет. Сделайте возможность ставить напоминания о событии за 3, 7 и 14 дней. После первой загрузки с интернетом календарь должен открываться и функционировать в офлайне.

Полезные ресурсы

Расписание фронтенд-конференций:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

Service workers:
developer.mozilla.org/ru/docs/Web/API/Service_Worker_API/Using_Service_Workers
developers.google.com/web/fundamentals/primers/service-workers

Notifications API:
developer.mozilla.org/ru/docs/Web/API/Notifications_API

The third task was the most interesting to test, because there were so many solutions, each with its own. We checked how the candidate handles unfamiliar technologies - whether he knows how to investigate, whether he tests his solutions.

Criteria

The made up calendar . Yes, he still needed to be made up. There were those who understood the condition too literally and did not insert a single line of CSS code. It did not look very personal, but if everything worked, the points did not decrease.

Retrieving a list of events from a source . This is not a task for typesetting, so the list of events sewn into it was not counted. You can always cancel the conference, reschedule it, add a new one. So it was required to receive data from the outside and render the layout already based on the received JSON. It was important in any way (using the fetch method or using XMLHttpRequest) to get the data. If a person added a polyfill for fetch and marked his choice in the readme, this counted as a plus.

Register service worker without errorsand work offline after the first download. Here is an example of a service worker with schedule caching on first boot. Details about service workers, their capabilities and ways of working with them (strategies for working with the cache, working offline) can be found here .

The ability to set a reminder so that it really works after 3, 7, 14 days. It was necessary to understand the Notifications API, the link to which was directly in the task. We did not wait for any specific implementation to verify whether the time has come for a push. Any working option was accepted: storage in localStorage, IndexDB or periodic polling by a service worker. You could even make a push server (here is an example), but it wouldn’t work offline. It was equally important to get a push after the page was closed - and opened after some time. If the reminder "died" at the same time as the page was closed, the decision did not count. It's cool when the guys thought about the inspectors and made the opportunity to get a push right now - so as not to wait 3 days.

The ability to make the icon on the desktop (PWA). We checked for the manifest.json file with the correct icons. Some guys made this file (or left the generated one in CreateReactApp) - but did not add the correct icons. Then, when trying to install, an error like “need another icon” occurred.

Code style and project structure. As in the second task, we looked at a single code style (even if it did not match ours). Some guys screwed linters - that's great.

Errors in the console . If there was an indicator directly in the console that something was wrong, and the participant did not pay attention to it, then we took points.

Summary

Funny in the decisions of the participants:

One questionnaire contained the following text: “A friend programmer helped to assemble the react application. I threw him questions of what, how and why, he told. I liked it very much, I want to know more about it. ” We wholeheartedly supported this questionnaire, but unfortunately, the candidate’s friend didn’t really help him make a working application.
One candidate sent a link to GitHub, where the RAR archive was located - it's hard to comment on this somehow. :)
Ещё один кандидат в комментарии первой строчки файла solution.js честно признался, что скопировал алгоритм.

We received questionnaires from 76 candidates and selected 23 of them. Questionnaires were sent to us not only from Minsk, but also from Moscow, St. Petersburg and even Tatarstan. Some guys surprised with their current professions: one of them is a medical examiner, and the other is a student at a medical university.

It turned out an interesting distribution of success in completing tasks. The participants completed the first task on average by 60%, the second - by 50%, and the third turned out to be the most difficult and it was completed on average by 40%.

At first glance, the tasks look complicated and time-consuming. The reason is not that we want to weed out as many candidates as possible. During training, students are faced with real tasks - to make a chat, Yandex.Music for children or Yandex.Weather for meteo-dependent people. To do this, you need a start base.

I remember how I saw my introduction to SRI two years ago and thought that I could never solve it. The main thing at this moment is to sit down, carefully read the conditions and start doing. It turns out that the conditions contain almost 80% of the solution. For example, in the condition of the third task (the most difficult), we added links to service workers and Notifications API on MDN. Students who studied the contents of the links coped without difficulty.

I really want this article to be read by candidates who plan to enter the SRI in the future, could not enter the Minsk School, or begin to do any other test task. As you can see, it’s quite possible to act. You only need to believe in yourself and listen to all the tips of the authors.

Interface development school: analysis of tasks for Minsk and a new set in Moscow

Task 1: Portfolio

Condition

Criteria

Task 2: Transport Route

Condition

Criteria

Task 3: Event Calendar

Condition

Полезные ресурсы

Criteria

Summary

Also popular now: