Yandex One Day Offer Tests
Ход конём [45 баллов]
Геннадий - интеллектуал. Он любит знакомиться с интересными людьми. Но будучи человеком осмотрительным и недоверчивым, делает он это только в интернете. Недавно Геннадий обнаружил, что сопоставимых по IQ собеседников можно отыскать на шахматном форуме, но вот беда - в шахматы играть Геннадий не умеет, а все обучаторы основаны на javascript-е, который Геннадий осмотрительно отключает, чтобы избежать вероятности подцепить вирус.
Чтобы помочь Геннадию - предлагаем сделать обучатор для игры в шахматы без javascript, который будет показывать, как ходит конь. Обучатор должен выглядеть как шахматная доска. Кликаешь по клетке - тебе показывают, куда с этой клетки может пойти конь.
Формат ввода
html-документ, при загрузке которого рисуется шахматная доска
Формат вывода
Задание будет протестировано в реальном браузере (Chrome 77).
В браузере будет загружен ваш html-документ. Робот кликает в различные ячейки шахматного поля и снимает скриншоты после кликов.
Скриншоты должны соответствовать эталонным
Пример
Примечания
- Реализация на CSS и HTML. Javascript использовать нельзя.
- Вся верстка должна быть квадратной, без теней, градиентов, скруглений и т.п.
- Ширина и высота ячейки - 30 пикселей
- Шахматное поле находится на странице слева сверху, без отступов
- Цвет выделенной ячейки #ff0000
- Цвет ячейки, на которую может ходить фигура #0000ff
- Цвет светлой ячейки #f4cd8d
- Цвет темной ячейки #745853
- Левая верхняя ячейка светлая
- Изначально ни одна ячейка не выделена
- Выделение происходит по клику в конкретную ячейку и сохраняется до следующего клика
Принцип «одного окна» [70 баллов]
Роботизированное агентство «Двое из ларца» занимается выполнением задач любой сложности за деньги клиентов. Работает агентство по принципу «одного окна». Сначала заказчик приносит список работ, которые нужно выполнить, с указанием приоритета каждой из них. Затем робот-менеджер вывешивает табличку «Ушёл на базу», уходит контролировать работу роботов-исполнителей, а когда те всё выполнят — возвращается и отдаёт клиентам отчёт о выполненных работах с квитанцией на оплату. Оплачивается только время активной работы роботов, без учёта простоя.
Чтобы клиенты могли заранее посчитать свои будущие расходы, вам нужно реализовать симулятор рабочего процесса в агентстве.
Формат ввода
Задачи для исполнения от заказчика имеют следующий формат:
const task = {
// строка, уникальный идентификатор задачи
id: "a1",
// число, приоритет задачи (от 1 до 1024)
priority: 10,
// функция, возвращающая Promise;
// Promise может быть resolved через длительное время
job: () => {
return new Promise((resolve, reject) => {
if (...) {
...
resolve();
} else reject();
});
}
};
Приоритет задачи — целое число. Чем больше число, тем больший приоритет у задачи.
Вам нужно реализовать класс TaskManager со следующими методами:
class TaskManager {
constructor(
N // общее число роботов-исполнителей (от 1 до 1024)
);
// Добавление задачи в очередь
addToQueue(
task // задача для исполнения, см. формат выше
);
// Promise, который запускает процесс выполнения задач и выдаёт список отчётов
run();
}
module.exports = { TaskManager };
У робота-менеджера две фазы работы
- Получение задач в очередь. В этот момент синхронно или асинхронно в очередь добавляются задачи при помощи вызова метода addToQueue. Количество задач не ограничено.
- Выполнение задач после вызова метода run. Все полученные ранее задачи берутся на выполнение. Свободные роботы берут задачи из очереди: самая приоритетная задача берётся первой, далее — по уменьшению приоритета и по времени поступления задачи в очередь.
Каждый робот в процессе формирует отчёт о выполнении работ:
{
// число — общее количество выполненных успешно задач
successCount: 2,
// число — общее количество невыполненных задач
failedCount: 1,
// массив строк — идентификаторы взятых задач по очереди
tasks: ["a1", "c3", "d4"],
// число — количество проведённых в работе миллисекунд
timeSpent: 203,
}
Задача может выполниться неуспешно (reject). Если успешно, то робот добавляет единицу в статистику к successCount. Если задача выполнилась неуспешно, то добавляет единицу к failedCount. Задача всё равно попадает в итоговый отчёт и учитывается в итоговом времени работы робота.
Формат вывода
Метод run менеджера возвращает Promise, который при resolve возвращает отчёт о проделанной роботами работе в виде массива отчётов каждого робота:
[
{
successCount: 2,
failedCount: 0,
tasks: ["a1", "d4"],
timeSpent: 203,
}, // отчёт робота номер 1
...,
{
successCount: 1,
failedCount: 1,
tasks: ["b2", "c3"],
timeSpent: 10,
}, // отчёт робота номер N
]
Примерный код для тестирования задачи
(async () => {
const generateJob = (id) =>
function () {
return new Promise((resolve, reject) => {
setTimeout(() => {
Math.random() > 0.8 ? resolve() : reject();
}, Math.random() * 2000);
});
};
const tm = new TaskManager(3);
tm.addToQueue({
id: "id0",
priority: 10,
job: generateJob("id0"),
});
tm.addToQueue({
id: "id1",
priority: 1,
job: generateJob("id1"),
});
tm.addToQueue({
id: "id2",
priority: 10,
job: generateJob("id2"),
});
tm.addToQueue({
id: "id3",
priority: 5,
job: generateJob("id3"),
});
const report = await tm.run();
console.log(report);
})();
Слишком надежный проект [90 баллов]
Слишком надежный проект
В Центре разработки тестирующей системы для тестового окружения написания тестов написаны тесты на каждую строчку кода системы. И после каждой правки кода разработчики должны не только написать новые тесты, но и протестировать изменения, чтобы удостовериться в надежности всей системы.
К сожалению, изначально решили запускать вообще все тесты. Последние запуски выполнялись по 42 года каждый, так что руководство центра решило внедрить оптимизации и запускать тесты только для измененных файлов.
Реализуйте функцию, которая будет выводить список запускаемых на правки тестов.
Формат ввода
Декларативное описание документа выглядит следующим образом:
{
// абсолютный путь до дирректории проекта в файловой системе
absoluteRepoPath: "/var/www/projects/project1",
// список алиасов по путям из исходной системы сборки
aliases: {
"@": "./src",
},
// информация обо всех модулях данного проекта
modules: [
{
// относительный от корня путь
file: "./src/pages/1.js",
deps: [
// валидная для исходной системы сборки строка, описывающая путь до модуля
// гарантируется, что такой модуль существует и описан в данной секции
"/var/www/projects/project1/src/pages/a.js",
"./b.js",
],
// был ли изменен программный код данного модуля
// ключ может не присутствовать, это означает, что код не был изменен
hasChanged: true,
},
{
file: "./src/pages/a.js",
deps: [
"@/pages/b.js"
],
},
{
file: "./src/pages/b.js",
deps: [],
hasChanged: true,
}
],
specs: [
// информация о тестах
{
file: "./src/specs/1.js",
deps: [
"/var/www/projects/project1/src/pages/a.js",
],
},
]
}
Следует понимать, что изменение является транзитивным отношением:
a.js -> b.js -> c.js -> d.js
Если модуль d.js изменен, это означает, что и все модули в цепочке выше тоже изменились: a.js b.js c.js
Формат вывода
Результатом работы алгоритма должен быть упорядоченный лексикографически массив необходимых для запуска тестов, где каждый тест описывается через абсолютный путь в файловой системе:
[
"/var/www/projects/project1/src/specs/1.js"
]
Если тесты запускать не требуется, указывается пустой массив.
[]
Межгалактический исследователь «Джаваскриптович» [90 баллов]
В недалеком будущем исследование новых планет стало обыденным хобби благодаря «Джаваскриптовичу» — самостоятельному беспилотному космическому зонду, который:
- проводит фотосъёмку в достаточно высоком разрешении: размер итоговой фотографии зачастую превышает 50 МБ,
- для анализа и обработки изображения запускает пользовательский код на языке Javascript.
Благодаря своей простоте «Джаваскриптович» активно применяется в исследовании космоса. Однако у него есть особенность — пользовательский код запускается в том же потоке, что и код, управляющий спутником. Поэтому нельзя блокировать поток дольше, чем на 50 мс, иначе зонд потеряет управление.
Ваша задача — написать CommonJS-модуль поиска контуров предметов на сделанных снимках. Модуль должен экспортировать функцию, которая принимает два аргумента: первый — UInt8ClampedArray с битмапом кадра (каждые 4 байта — один пиксель в формате rgba), второй аргумент — объект, содержащий свойства width (ширина кадра) и height (высота кадра).
Требуется реализовать следующий алгоритм поиска контуров:
- Перевести кадр в оттенки серого по формуле 0.21 R + 0.72 G + 0.07 B.
- К результату п. 1 применить фильтр Dilation с окном 3х3 px.
- К результату п. 1 применить фильтр Erosion с окном 3х3 px.
- Вычесть попиксельно результат п. 3 из результата п. 2.
- Однопиксельную границу кадра закрасить чёрным.
- Применить к результату пороговую функцию со значением порога 90.
Функция должна возвращать promise с Uint8ClampedArray, в котором каждое значение равно 0 либо 255 и соответствует пикселю исходной картинки.
Алгоритм не должен блокировать главный поток дольше, чем на 50 мс. Использовать shared worker’ы запрещено. Суммарное время обработки одного кадра не должно быть слишком большим.
Описание фильтров Dilation и Erosion.
В архиве по ссылке «скачать условие задачи» вы найдёте страницу, которую можно использовать для отладки.