Денеска се отвори нов упис во во Москва. Првата фаза од обуката ќе се одржи од 7 септември до 25 октомври. Во него ќе може да учествуваат студенти од други градови од далечина или лично - компанијата ќе плаќа патување и сместување во хостел. Втората, воедно и завршна фаза, ќе трае до 3 декември, може да се заврши само лично.
Јас се викам Јулија Середич, го напишавме овој пост заедно со Сергеј Казаков. И двајцата сме развивачи на интерфејси во канцеларијата на Yandex во Минск и дипломци на SRI од претходните години.
По повод отворањето на регистрацијата во Москва, објавуваме анализа на воведните задачи на претходното училиште - овде во Минск.
Ако ја следите историјата на задачите за SRI, од година во година тестиравме три важни вештини за програмер:
- Распоред. Секој развивач треба да може да направи распоред. Не се случува да го имате чичко Сериожа кој дизајнира за целиот тим, а вие да пишувате само сценарија. Затоа, секој ученик мора да покаже како знае да наборува.
- JavaScript. Ако работата беше ограничена на распоред, тогаш немаше да имаме школа за развој на интерфејс, туку школа за дизајнери на распоред. Прекрасно дизајнираниот интерфејс треба да се оживее. Затоа, секогаш има задача за JS, но понекогаш тоа е задача и за алгоритми - толку многу ги сакаме.
- Решавањето проблеми е можеби најважната вештина на развивачот. Кога станува збор за креирање интерфејси, работите се менуваат многу брзо. Тоа е како Луис Керол: „Треба да трчате најбрзо што можете само за да останете на истото место, а за да стигнете на друго место треба да трчате двојно побрзо“. Секојдневно наидуваме на нови технологии - треба да ги земеме предвид и да можеме да ги разбереме. Затоа, во третата задача, предложивме да ги разбереме технологиите со кои почетниот програмер обично не е запознаен.
Во анализата на секоја задача, ќе ви кажеме не само за правилната процедура, туку и за вообичаените грешки.
Задача 1: Портфолио
На првата задача работеа дизајнерот на Yandex.Collections, Алексеј Черенкевич, кој знае да прави распоред, и неговиот колега од сервисот, развивачот на интерфејси Сергеј Самсонов.
Состојба
Направете веб-страница за портфолио: кажете ни за себе, за вашата работа и за вашите очекувања од училиштето. Веб-страницата треба да одговара колку што е можно повеќе со предложениот распоред (врски до распоред: , , , ). Ние сме заинтересирани само за изгледот, затоа ве молиме не користете JavaScript.
При проверка ќе ги земеме предвид:
- големини на вдлабнатини, исправност на бојата, стил на фонт, големина на фонтот;
- семантички распоред;
- присуство на различни состојби на елементи: прикажување копчиња и врски при лебдење на курсорот, истакнување на активни полиња за внесување итн.;
- компатибилност со вкрстени прелистувачи (тестиран во најновите верзии на популарните прелистувачи).
Предноста ќе биде:
- употреба на современи CSS решенија: flexbox, grid итн.;
- Прилагодлив распоред;
- употреба на пред и (или) пост-процесори, склопување, минификување, оптимизација на излезниот код;
- Валидација на HTML форма, стилизирано копче за поставување датотека.
Задачата е доста обемна, па можете да го прескокнете она што нема да работи. Ова малку ќе го намали вашиот резултат, но сепак ќе можете да го покажете вашето знаење. Кога ќе завршите, испратете ни две врски - до вашето портфолио и изворниот код на GitHub.
Распоредот предложени во задачата не беше само со екрани за мобилни уреди, таблети и десктоп компјутери, туку и со реални спецификации.
За да се внесе што поголема објективност во резултатот од проверката на првата задача, имаше многу критериуми за оваа проверка.
критериуми
Дизајнирана веб-страница. Ова изгледа очигледно, но некои момци целосно прескокнаа некои блокови - или сакаа да заштедат време, или не можеа да ги направат. Распоредот може грубо да се подели на четири главни екрани: главен екран со аватар, блок со листа на очекувања од SRI, блок со портфолио и блок со информации за контакт. Тие може да се направат во делови или едноставно со користење на divs, главната работа е што сите четири блока беа достапни.
Усогласеност на распоредот со распоредот. Дизајнерот направи посебна спецификација (вклучувајќи бои, типографија, состојби на копчиња итн.) за да им олесни на кандидатите. На дното имаше навестување за вдлабнатините и карактеристиките на првиот екран. Бев многу задоволен од момците кои ги земаа предвид сите желби на дизајнерот: на пример, првиот екран требаше да биде не помал од висината на погледот.
Прилагодлив распоред - ова е кога интерфејсот не е само поставен така што при три резолуции сè е од пиксел до пиксел во распоредот. Во средните состојби, ниту распоредот не треба да се распаѓа. Некои заборавија да ја ограничат максималната ширина на контејнерот и поставија сè на 1920 пиксели, некои ја измешаа позадината, но генерално кандидатите добро се справија со оваа задача.
Семантички распоред. „Колку пати му кажале на светот“ дека врската треба да биде дизајнирана како , копче - како . За среќа, повеќето кандидати го исполнија и ова барање. Не сите ја препознаа скриената листа во очекувањата на SRI, правејќи ја да користи div ознаки, но тоа не е толку лошо. Имаше еден кандидат кој ги вметнуваше сите семантички ознаки што ги знаеше - каде треба и каде не треба. На пример, наместо список - и . На крајот на краиштата, семантика - се работи за разбирање на составот на вашата страница и целта на секој блок (мнозинството успеало тука), како и употребата на пред-и/или пост-процесори (некои успеале тука, иако ова беше и во точките - најчесто користеле помалку и ссс) .
Работен лизгач. Во задачата напишавме дека JS не може да се користи. Овде беше тестирана способноста за решавање проблеми - можеше да се направи лизгач користејќи комбинација од и . Целата магија се случува на ниво на селекторот #button-N:checked ~ .slider-inner .slider-slides. Кога ќе кликнеме на едно од полињата за избор за внесување, тоа оди во штиклирана состојба. Можеме да го искористиме ова и да го доделиме преводот што ни треба на контејнерот со слајдовите: transform: translate(-33%). Можете да ја видите имплементацијата на лизгачот .
Паѓачки списоци. Тука сè се сведе на и сличен избирач: .accordion-item input:checked ~ .accordion-item__content. Можете да ја видите имплементацијата .
Достапност на состојби :hover, :active и :focu*. Многу важна точка. Удобноста за време на интеракцијата со интерфејсот зависеше од тоа. Корисникот секогаш треба да добива повратни информации за неговите постапки. Оваа ставка беше проверувана во текот на интеракцијата со прашалникот. Ако кликнав на копчето „Повикај ме“ и визуелно ништо не се случи (иако барањето беше испратено), ова е лошо, бидејќи тогаш ќе го кликнам повторно и повторно. Како резултат на тоа, ќе бидат испратени десет барања и десет пати ќе бидам повикан назад. Не смееме да заборавиме дека мобилните уреди немаат глушец, што значи дека не треба да има лебдење. И уште една точка која не ги погоди тие што ја исполнија поентата за семантиката. Ако вашата контрола не е интерактивен елемент, тогаш кога ќе лебдите над неа курсорот ќе остане стандарден. Изгледа многу неуредно, дури и ако сте напишале реакција на лебди. Не го потценувајте курсорот: покажувач.
Анимации. Важно е сите реакции што се случуваат со елементите да бидат мазни. Ништо во животот не е моментално, така што имањето транзиции на лебди и активни беше доволно за да го направи интерфејсот попријатен. Па, оние што го анимираа лизгачот и списоците се генерално одлични.
Користење на најнова технологија. Многу луѓе користеа флекс, но никој не ја заврши задачата користејќи мрежа. Поенот се броеше ако флекс се користеше правилно. Ако некаде распоредот се распадна поради овие флексии, за жал, не сте добиле дополнителни поени.
Валидација на формуларот. Сè што беше потребно беше да се додаде бараниот атрибут на секој влез во формуларот. Додадовме поени на оние кои го потврдија полето за е-пошта како е-пошта.
Стилизирање на копчето за поставување датотека. Очекувавме да видиме комбинација како: и Изберете датотека. Следно, требаше да го скриеме влезот и да ја стилизираме етикетата. Постои уште еден вообичаен начин - да се направи транспарентен влез и да се стави на врвот на копчето. Но, не сите прелистувачи дозволуваат стилизирање на и ова решение не може да се нарече целосно вкрстено прелистувач. И семантички е поправилно да се направи етикета.
Компатибилност со вкрстени прелистувачи. Проверивме дека се е во ред во двете најнови верзии на модерни прелистувачи (без IE - учесниците имаа среќа), како и во Safari на iPhone и Chrome на Android.
Напротив, одземавме поени ако некој користи JS или Bootstrap: и двајцата ќе ја поразат целта на целата задача. Покрај тоа, учесниците со Bootstrap не само што добија минус, туку изгубија и многу поени за семантика и имплементирани елементи.
Оние кои го хостираа својот сајт некаде на Интернет не добија некоја посебна предност - но рецензентите беа многу среќни кога не мораа да преземаат складишта и да ги извршуваат локално на нивниот компјутер. Така, ова служеше како плус за кармата.
Првата задача беше многу корисна првенствено за ученикот. Оние што не ги прифативме сега имаат подготвено резиме - можете гордо да го прикачите на сите одговори или да го објавите на вашите gh-страници.
Задача 2: Транспортен пат
Авторот на задачата е шефот на групата за интерфејси за пребарување Денис Балико.
Состојба
Дали имате ѕвездена мапа? Го покажува името на секоја ѕвезда, како и растојанието од неа до другите ѕвезди во светлосни секунди. Имплементирајте ја функцијата за решение, која треба да земе три аргументи: објект во кој копчињата се имињата на ѕвездите, а вредностите се растојанијата до ѕвездите (еднонасочен сообраќај во вселената), како и имињата на почетната и завршната точка на патеката - почеток и крај, соодветно. Функцијата треба да го врати најкраткото растојание од почетната ѕвезда до целната ѕвезда и патеката што треба да се следи.
Потпис на функцијата:
const solution = function(graph, start, finish) { // Ваше решение }Пример за влезни податоци:
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';Пример излез:
{ distance: 90, path: ['start', 'A', 'D', 'finish'] }Забелешка: Скелетот на решението е во папката src/, ставете го вашето решение во solution.js.
Верификацијата на втората задача беше најавтоматизирана и најобјективна. Повеќето момци погодија дека е неопходно да се имплементира алгоритмот на Дијкстра. Оние кои го пронајдоа неговиот опис и го имплементираа алгоритмот во ЈС се добро направено. Меѓутоа, при проверка на задачата наидовме на многу трудови со исти грешки. Пребарувавме на Интернет за фрагменти од код и најдовме статија од која учесниците го копираа алгоритмот. Смешно е што многу луѓе го копираа кодот од статијата заедно со коментарите на авторот. Ваквите дела добија ниска оценка. Ние не забрануваме употреба на никакви извори, но сакаме човекот да навлезе во она што го пишува.
критериуми
Главните поени беа доделени за тестови. Понекогаш беше јасно дека момците се мешаат со складиштето, ги преименуваа папките и тестовите ќе пропаднат едноставно затоа што не можеа да ги најдат потребните датотеки. Оваа година се обидовме да им помогнеме на таквите момци и им вративме се на своето место. Но, следната година планираме да се префрлиме на систем за натпреварување, и тоа повеќе нема да ни се простува.
Имаше и „човечки“, рачни критериуми. На пример, присуството на еден стил на код. Никој не одзема поени за користење јазичиња наместо празни места или обратно. Друго прашање е ако наизменично ги менувате единечните наводници со двојни наводници според едно добро познато правило и ставате точки запирки по случаен избор.
Јасноста и читливоста на решението беа земени посебно во предвид. На сите конференции во светот велат дека 80% од работата на програмерот се состои од читање на туѓиот код. Дури и учениците се подложени на прегледи на кодови - од нивните куратори и едни од други. Значи, овој критериум имаше значителна тежина. Имаше дела во кои немаше променливи подолги од еден знак - немојте да го правите тоа. Коментарите од учесниците беа многу охрабрувачки - со исклучок на оние кои беа идентични со коментарите на Стела Чанг.
Последниот критериум е присуството на автотестови. Само неколку луѓе ги додадоа, но за сите тоа стана огромен плус во нивната карма.
Точно решение:
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);
};
};Задача 3: Календар на настани
Го подготвија развивачите на интерфејс Сергеј Казаков и Александар Подскребкин.
Состојба
Напишете мини-календар за да го прикажете вашиот распоред. Можете да земете кој било распоред што го сакате. На пример, распоредот на фронтенд конференции во 2019 година.
Календарот треба да изгледа како листа. Нема други барања за дизајн. Овозможете поставување потсетници за настани 3, 7 и 14 дена однапред. По првото преземање од Интернет, календарот треба да се отвори и да функционира офлајн.
Корисни ресурси
Распоред на конференцијата на Frontend:
Услужни работници:
API за известувања:
Третата задача беше најинтересна за тестирање, бидејќи имаше толку многу можни решенија, секое со свое. Проверивме како кандидатот се справува со непознати технологии - дали знае да истражува, дали ги тестира своите решенија.
критериуми
Преклопен календар. Да, сè уште требаше да се постави. Имаше и такви кои условот го сфатија премногу буквално и не вметнаа ниту една линија CSS код. Не изгледаше многу привлечно, но ако сè функционираше, бодовите не се намалија.
Добивање листа на настани од извор. Ова не е задача за распоред, така што листата на настани вклучени во неа не се брои. Секогаш можете да откажете конференција, да ја презакажете или да додадете нова. Значи, беше неопходно да се примаат податоци однадвор и да се рендерира распоредот врз основа на примениот JSON. Беше важно да се добијат податоците на кој било начин (користејќи го методот на превземање или користејќи XMLHttpRequest). Ако некое лице додаде полифил за fetch и го означил својот избор во readme, ова се сметало како плус.
Регистрација на сервисен работник без грешки и работете офлајн по првото преземање. сервисен работник со распоред за кеширање при првото подигање. Детали за услужните работници, нивните способности и начини на работа со нив (стратегии за работа со кеш, работа офлајн) може да се најдат овде.
Способност да поставите потсетниктака што всушност работи по 3, 7, 14 дена. Беше неопходно да се разбере API за известувања, беше во право на задачата. Не очекувавме некоја конкретна имплементација за да провериме дали е време за притисок. Секоја работна опција беше прифатена: складирање во localStorage, IndexDB или периодично гласање од сервисер. Дури беше можно да се направи push-сервер (тука ), но нема да работи офлајн. Подеднакво беше важно да се добие притисок откако страницата беше затворена - и отворена по некое време. Ако потсетникот изумре во исто време кога страницата беше затворена, решението не се броеше. Убаво е кога момците размислуваа за рецензентите и овозможија да се поттикнат токму сега - за да не чекаат 3 дена.
Можност за поставување икона на работната површина (PWA). Го проверивме присуството на датотеката со правилни икони. Некои момци ја направија оваа датотека (или ја оставија генерирана во CreateReactApp) - но не ги додадоа точните икони. Потоа, при обидот да се инсталира, се појави грешка како „потребна е друга икона“.
Codestyle и структура на проектот. Како и во втората задача, погледнавме единствен стил на код (дури и ако не се совпаѓа со нашиот). Некои момци се навртуваат на линтери - тоа е одлично.
Грешки во конзолата. Ако точно во конзолата имаше индикатор дека нешто не е во ред, а учесникот не обрнуваше внимание на тоа, тогаш одземавме поени.
Резултатите од
Што е смешно во одлуките на учесниците:
- Еден прашалник го содржеше следниов текст: „Еден пријател програмер ми помогна да составам апликација React. Го бомбардирав со прашања како и зошто, а тој ми кажа. Навистина ми се допадна, сакам да знам повеќе за тоа“. Со сето срце навивавме за оваа апликација, но, за жал, пријателот на кандидатот не ни помогна многу за апликацијата да функционира.
- Еден кандидат испрати врска до GitHub, каде што се наоѓа архивата на RAR - тешко е да се коментира за ова. 🙂
- Друг кандидат, во коментарот на првата линија од датотеката solution.js, искрено призна дека го копирал алгоритмот.
Добивме пријави од 76 кандидати и избравме 23 лица. Ни беа испратени прашалници не само од Минск, туку и од Москва, Санкт Петербург, па дури и од Татарстан. Некои од момците не изненадија со сегашните професии: едниот е судски вештак, а другиот студент по медицина.
Резултатот беше интересна дистрибуција на стапки на успех во завршувањето на задачите. Првата задача учесниците ја завршија просечно 60%, втората за 50%, а третата испадна најтешка и беше завршена во просек за 40%.
На прв поглед, задачите изгледаат сложени и одземаат многу време. Причината не е тоа што сакаме да отстраниме што е можно повеќе кандидати. За време на нивните студии, студентите се соочуваат со задачи од реалниот живот - правење разговор, Yandex.Music за деца или Yandex.Weather за луѓе зависни од временските услови. За ова ви треба почетна основа.
Се сеќавам дека ја видов мојата задача за влез во СРИ пред две години и мислев дека никогаш нема да ја решам. Главната работа во овој момент е да седнете, внимателно да ги прочитате условите и да почнете да го правите тоа. Излегува дека условите содржат речиси 80% од растворот. На пример, во состојбата на третата задача (најтешката), додадовме врски до сервисери и API за известувања на MDN. Учениците кои ја проучувале содржината на врските ја завршиле без потешкотии.
Навистина би сакал овој напис да биде прочитан од кандидати кои планираат да влезат во СРИ во иднина, кои не можеа да влезат во школата во Минск или кои почнуваат да прават некоја друга тест задача. Како што можете да видите, тоа е сосема можно да се направи. Треба само да верувате во себе и да ги слушате сите совети од авторите.
Извор: www.habr.com