Škola vývoje rozhraní: analýza úkolů pro Minsk a nový soubor v Moskvě

Dnes byla otevřena nová přihláška Yandex Interface Development School v Moskvě. První etapa školení bude probíhat od 7. září do 25. října. Studenti z jiných měst se do něj budou moci zapojit na dálku nebo osobně – firma zaplatí cestu a ubytování v ubytovně. Druhá, rovněž závěrečná etapa, potrvá do 3. prosince, absolvovat ji lze pouze osobně.

Jmenuji se Julia Seredich, tento příspěvek jsme napsali společně se Sergejem Kazakovem. Oba jsme vývojáři rozhraní v Minské kanceláři Yandex a absolventi SRI z předchozích let.

Škola vývoje rozhraní: analýza úkolů pro Minsk a nový soubor v Moskvě

U příležitosti zahájení registrace v Moskvě zveřejňujeme rozbor úvodních úkolů do předchozí Školy - zde v Minsku.

Pokud sledujete historii zadání SRI, rok od roku jsme testovali tři důležité dovednosti pro programátora:

  • Rozložení. Každý vývojář by měl umět udělat layout. Nestane se, že máte strýčka Seryozhu, který navrhuje pro celý tým, a vy jen píšete scénáře. Každý student proto musí ukázat, jak umí sázet.
  • JavaScript. Pokud by se záležitost omezila na rozvržení, pak bychom neměli Školu vývoje rozhraní, ale Školu návrhářů rozvržení. Krásně navržené rozhraní je třeba oživit. Proto vždy existuje úkol pro JS, ale někdy je to také úkol pro algoritmy - máme je tak rádi.
  • Řešení problémů je možná nejdůležitější dovedností vývojáře. Pokud jde o vytváření rozhraní, věci se velmi rychle mění. Je to jako Lewis Carroll: "Musíte běžet tak rychle, jak můžete, jen abyste zůstali na stejném místě, a abyste se dostali na jiné místo, musíte běžet dvakrát rychleji." Každý den se setkáváme s novými technologiemi – je třeba je brát v úvahu a umět jim porozumět. Proto jsme ve třetím úkolu navrhli porozumět technologiím, které začínající vývojář obvykle nezná.

V rozboru každého úkolu vám prozradíme nejen správný postup, ale i časté chyby.

Úkol 1: Portfolio

Na prvním úkolu pracoval designér Yandex.Collections Alexey Cherenkevich, který ví, jak dělat layout, a jeho servisní kolega, vývojář rozhraní Sergey Samsonov.

Stav

Vytvořte webové stránky portfolia: řekněte nám o sobě, své práci a svých očekáváních od školy. Stránka by měla co nejvíce odpovídat navrženému rozložení (odkazy na rozložení: 1000px, 600px, 320px, Specifikace). Zajímá nás pouze rozvržení, proto prosím nepoužívejte JavaScript.

Při kontrole budeme brát v úvahu:

  • velikosti odsazení, barevná správnost, styl písma, velikost písma;
  • sémantické rozložení;
  • přítomnost různých stavů prvků: zobrazení tlačítek a odkazů při najetí kurzorem, zvýraznění aktivních vstupních polí atd.;
  • kompatibilita mezi různými prohlížeči (testováno v nejnovějších verzích oblíbených prohlížečů).

Výhodou bude:

  • využití moderních CSS řešení: flexbox, grid atd.;
  • Adaptivní uspořádání;
  • použití pre- a (nebo) post-procesorů, sestavení, minifikace, optimalizace výstupního kódu;
  • Ověření formuláře HTML, tlačítko pro nahrání stylizovaného souboru.

Úkol je poměrně objemný, takže můžete přeskočit, co nebude fungovat. Tím se vaše skóre mírně sníží, ale stále budete moci prokázat své znalosti. Až budete hotovi, pošlete nám dva odkazy – na vaše portfolio a zdrojový kód na GitHubu.

Rozvržení navržené v zadání nebyly jen s obrazovkami pro mobilní zařízení, tablety a desktopy, ale také s reálnými specifikacemi.

Aby výsledek kontroly prvního úkolu vnesl co nejvíce objektivity, bylo pro tuto kontrolu mnoho kritérií.

kritéria

Navržený web. Zdá se to zřejmé, ale někteří kluci některé bloky úplně vynechali - buď chtěli ušetřit čas, nebo je nemohli udělat. Rozložení lze zhruba rozdělit do čtyř hlavních obrazovek: hlavní obrazovka s avatarem, blok se seznamem očekávání od SRI, blok s portfoliem a blok s kontaktními informacemi. Daly se dělat po sekcích nebo jednoduše pomocí divů, hlavní je, že byly k dispozici všechny čtyři bloky.

Soulad dispozice s dispozicí. Návrhář vytvořil samostatnou specifikaci (včetně barev, typografie, stavu tlačítek atd.), aby to kandidátům usnadnil. Ve spodní části byl náznak odsazení a funkcí první obrazovky. Byl jsem velmi potěšen kluky, kteří vzali v úvahu všechna přání designéra: například první obrazovka neměla být menší než výška výřezu.

Adaptivní rozložení - to je, když rozhraní není jen rozvrženo tak, že při třech rozlišeních je vše v rozložení pixel po pixelu. V mezistavech by se rozložení také nemělo rozpadat. Někdo zapomněl omezit maximální šířku kontejneru a vše nastavil na 1920 pixelů, někdo pokazil pozadí, ale celkově se kandidáti s tímto úkolem vypořádali dobře.

Sémantické rozložení. „Kolikrát řekli světu“, že odkaz by měl být navržen jako , tlačítko – jako . Naštěstí i tento požadavek většina uchazečů splnila. Ne každý rozpoznal skrytý seznam v očekáváních SRI, takže se používá pomocí značek div, ale není to tak špatné. Byl kandidát, který vložil všechny sémantické značky, které znal – tam, kde to bylo nutné a kde to nebylo nutné. Například místo seznamu - a . Koneckonců sémantika - jde o pochopení složení vaší stránky a účelu každého bloku (tady to zvládla většina), stejně jako použití pre- a/nebo post-procesorů (několik tu to zvládlo, i když tohle byl také v bodech - nejčastěji používali méně a scss) .

Pracovní posuvník. V zadání jsme psali, že JS nelze použít. Zde se testovala schopnost řešit problémy - pomocí hromady se dal vyrobit posuvník a . Všechna kouzla se odehrávají na úrovni voliče #button-N:checked ~ .slider-inner .slider-slides. Když klikneme na jedno ze vstupních zaškrtávacích políček, přejde do zaškrtnutého stavu. Můžeme toho využít a do kontejneru se snímky přiřadit překlad, který potřebujeme: transform: translate(-33%). Můžete vidět implementaci posuvníku zde.

Rozbalovací seznamy. Tady to také všechno dopadlo a podobný selektor: .accordion-item input:checked ~ .accordion-item__content. Můžete vidět realizaci zde.

Dostupnost stavů :hover, :active a :focu*. Velmi důležitý bod. Záleželo na tom pohodlí při interakci s rozhraním. Uživatel by měl vždy dostávat zpětnou vazbu o své činnosti. Tato položka byla kontrolována po celou dobu interakce s dotazníkem. Pokud jsem kliknul na tlačítko „Zavolejte mi“ a vizuálně se nic nestalo (i když požadavek byl odeslán), je to špatně, protože na to budu klikat znovu a znovu. Ve výsledku bude odesláno deset žádostí a desetkrát mi zavolají zpět. Nesmíme zapomínat, že mobilní zařízení nemají myš, což znamená, že by nemělo docházet k vznášení. A ještě jeden bod, který neovlivnil ty, kteří splnili bod o sémantice. Pokud váš ovládací prvek není interaktivní prvek, pak když na něj najedete, kurzor zůstane standardní. Vypadá to velmi neupraveně, i když jste napsali reakci na vznášení. Nepodceňujte kurzor: ukazatel.

Animace. Je důležité, aby všechny reakce probíhající s prvky byly plynulé. Nic v životě není okamžité, takže mít přechody na houpačce a aktivní stačilo ke zpříjemnění rozhraní. No, ti, kteří animovali posuvník a seznamy, jsou obecně skvělí.

Použití nejnovější technologie. Mnoho lidí používalo flex, ale nikdo nedokončil úkol pomocí mřížky. Bod byl započítán, pokud byl flex použit správně. Pokud se někde rozložení rozpadlo právě kvůli těmto ohybům, bohužel jste nezískali žádné další body.

Ověření formuláře. Vše, co bylo požadováno, bylo přidat požadovaný atribut do každého vstupu formuláře. Přidali jsme body těm, kteří ověřili pole e-mailu jako e-mail.

Stylování tlačítka pro nahrání souboru. Očekávali jsme, že uvidíme kombinaci jako: a Vyberte soubor . Dále jsme potřebovali skrýt vstup a nastylovat popisek. Existuje další běžný způsob - vytvořit průhledný vstup a umístit jej na tlačítko. Ne všechny prohlížeče ale umožňují styling , a takové řešení nelze nazvat plně cross-browser. A sémanticky správnější je štítek udělat.

Kompatibilita mezi prohlížeči. Zkontrolovali jsme, že je vše v pořádku ve dvou nejnovějších verzích moderních prohlížečů (bez IE – účastníci měli štěstí), stejně jako v Safari na iPhonech a Chrome na Androidech.

Naopak jsme odečítali body, pokud někdo použil JS nebo Bootstrap: obojí by zmařilo účel celého úkolu. Navíc účastníci s Bootstrap nejen dostali mínus, ale také ztratili mnoho bodů za sémantiku a implementované prvky.

Ti, kteří své stránky hostovali někde na internetu, nezískali žádnou zvláštní výhodu – ale recenzenti byli velmi rádi, když nemuseli stahovat úložiště a spouštět je lokálně na svém počítači. Takže to posloužilo jako plus pro karmu.

První úkol byl velmi užitečný především pro studenta. Ti, které jsme nepřijali, mají nyní připravený životopis - můžete jej hrdě připojit ke všem odpovědím nebo ho umístit na své gh-stránky.

Úkol 2: Dopravní trasa

Autorem úkolu je vedoucí skupiny vyhledávacích rozhraní Denis Balyko.

Stav

Máte hvězdnou mapu? Zobrazuje jméno každé hvězdy a také vzdálenost od ní k ostatním hvězdám ve světelných sekundách. Implementujte funkci řešení, která by měla mít tři argumenty: objekt, ve kterém jsou klíče názvy hvězd a hodnoty jsou vzdálenosti ke hvězdám (jednosměrný provoz ve vesmíru), stejně jako názvy hvězd. počáteční a koncový bod cesty - začátek a konec. Funkce by měla vrátit nejkratší vzdálenost od počáteční hvězdy k cílové hvězdě a cestu, kterou je třeba sledovat.

Podpis funkce:

const solution = function(graph, start, finish)  {
    // Ваше решение
} 

Příklad vstupních dat:

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'; 

Příklad výstupu:

{
    distance: 90,
    path: ['start', 'A', 'D', 'finish']
} 

Poznámka: Kostra řešení je ve složce src/, své řešení vložte do souboru solution.js.

Ověření druhého úkolu bylo nejvíce automatizované a objektivní. Většina chlapů uhádla, že je nutné implementovat Dijkstrův algoritmus. Ti, kteří našli jeho popis a implementovali algoritmus v JS, mají dobrou práci. Při kontrole zadání jsme však narazili na mnoho papírů se stejnými chybami. Hledali jsme na internetu fragmenty kódu a našli jsme článek, ze kterého účastníci zkopírovali algoritmus. Je legrační, že mnoho lidí zkopírovalo kód z článku spolu s komentáři autora. Takové práce získaly nízké hodnocení. Nezakazujeme používat žádné zdroje, ale chceme, aby se člověk ponořil do toho, co napíše.

kritéria

Hlavní body byly uděleny za testy. Někdy bylo jasné, že se kluci pletli s úložištěm, přejmenovávali složky a testy selhaly jednoduše proto, že nemohli najít potřebné soubory. Letos jsme se snažili takovým klukům pomoci a vrátili jim vše na své místo. Příští rok ale plánujeme přejít na soutěžní systém, a to se už neodpustí.

Existovala také „lidská“, manuální kritéria. Například přítomnost jediného stylu kódu. Nikdo neodečítal body za použití tabulátorů místo mezer nebo naopak. Jiná věc je, když střídáte jednoduché uvozovky s dvojitými podle jednoho vám známého pravidla a středníky umístíte náhodně.

Samostatně byla zohledněna přehlednost a čitelnost řešení. Na všech konferencích ve světě říkají, že 80 % práce programátora spočívá ve čtení kódu jiných lidí. I školáci podstupují code review – od svých kurátorů i od sebe navzájem. Takže toto kritérium mělo významnou váhu. Byly práce, ve kterých nebyly žádné proměnné delší než jeden znak – prosím nedělejte to. Komentáře účastníků byly velmi povzbudivé – s výjimkou těch, které byly totožné s komentáři Stelly Changové.

Posledním kritériem je přítomnost autotestů. Přidalo si je jen pár lidí, ale pro všechny se to stalo obrovské plus v karmě.

Správné řešení:

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);
    };
};

Úkol 3: Kalendář událostí

Připravili jej vývojáři rozhraní Sergey Kazakov a Alexander Podskrebkin.

Stav

Napište si minikalendář, který zobrazí váš rozvrh. Můžete si vzít libovolný rozvrh. Například harmonogram frontendových konferencí v roce 2019.

Kalendář by měl vypadat jako seznam. Neexistují žádné další požadavky na design. Umožněte nastavit připomenutí událostí 3, 7 a 14 dní předem. Po prvním stažení z internetu by se měl kalendář otevřít a fungovat offline.

Užitečné zdroje

Program frontendové konference:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

Servisní pracovníci:
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

Třetí úkol byl nejzajímavější na testování, protože bylo tolik možných řešení, z nichž každé mělo své vlastní. Ověřili jsme si, jak uchazeč zachází s neznámými technologiemi – zda ​​umí zkoumat, zda testuje svá řešení.

kritéria

Skládaný kalendář. Ano, ještě to bylo potřeba rozložit. Našli se i tací, kteří vzali podmínku příliš doslovně a nevložili ani řádek kódu CSS. Nevypadalo to moc lákavě, ale pokud vše fungovalo, body neubývaly.

Získání seznamu událostí ze zdroje. Toto není úkol rozvržení, takže seznam událostí v něm obsažených nebyl započítán. Konferenci můžete kdykoli zrušit, přeplánovat nebo přidat novou. Bylo tedy nutné přijímat data zvenčí a vykreslovat rozložení na základě přijatého JSON. Důležité bylo získat data jakýmkoliv způsobem (pomocí metody fetch nebo pomocí XMLHttpRequest). Pokud osoba přidala polyfill pro načtení a označila svou volbu v readme, bylo to započítáno jako plus.

Registrace servisního pracovníka bez chyb a pracovat offline po prvním stažení. Zde je příklad. servisní pracovník s plánováním ukládání do mezipaměti při prvním spuštění. Podrobnosti o servisních pracovnících, jejich možnostech a způsobech práce s nimi (strategie práce s cache, práce offline) naleznete zde.

Možnost nastavit připomínkuaby to skutečně fungovalo po 3, 7, 14 dnech. Bylo nutné porozumět rozhraní Notifications API, odkaz na který byl přímo v úkolu. Neočekávali jsme žádnou konkrétní implementaci, která by prověřila, zda je čas tlačit. Byla přijata jakákoli pracovní možnost: úložiště v localStorage, IndexDB nebo pravidelné dotazování servisním pracovníkem. Bylo dokonce možné vytvořit push server (zde příklad), ale nefungovalo by to offline. Stejně důležité bylo obdržet zatlačení poté, co byla stránka zavřena – a po nějaké době otevřena. Pokud připomenutí zemřelo ve stejnou dobu, kdy byla stránka uzavřena, řešení se nezapočítávalo. Je skvělé, když kluci mysleli na recenzenty a umožnili jim dostat se hned teď – aby nemuseli čekat 3 dny.

Možnost umístit ikonu na plochu (PWA). Zkontrolovali jsme přítomnost souboru manifest.json se správnými ikonami. Někteří kluci vytvořili tento soubor (nebo jej nechali vygenerovat v CreateReactApp) - ale nepřidali správné ikony. Poté se při pokusu o instalaci vyskytla chyba jako „je potřeba jiná ikona“.

Kódový styl a struktura projektu. Stejně jako v druhém úkolu jsme se podívali na jediný kódový styl (i když se neshodoval s naším). Někteří chlapi našroubovali lintry - to je skvělé.

Chyby konzole. Pokud byl přímo v konzole indikátor, že něco není v pořádku, a účastník tomu nevěnoval pozornost, odečetli jsme body.

Výsledky

Co je vtipného na rozhodování účastníků:

  • Jeden dotazník obsahoval následující text: „Kamarád programátor mi pomohl sestavit aplikaci React. Zasypal jsem ho otázkami, jak a proč, a on mi to řekl. Moc se mi to líbilo, chci se o tom dozvědět víc." Této aplikaci jsme fandili z celého srdce, ale bohužel přítel kandidáta nebyl příliš nápomocný při zprovoznění aplikace.
  • Jeden kandidát poslal odkaz na GitHub, kde se nacházel archiv RAR – je těžké se k tomu vyjádřit. 🙂
  • Jiný kandidát v komentáři na prvním řádku souboru solution.js upřímně přiznal, že algoritmus zkopíroval.

Obdrželi jsme přihlášky od 76 uchazečů a vybrali jsme 23 lidí. Byly nám zaslány dotazníky nejen z Minsku, ale také z Moskvy, Petrohradu a dokonce i Tatarstánu. Někteří kluci nás překvapili svými současnými profesemi: jeden z nich je soudní znalec a druhý student medicíny.

Výsledkem bylo zajímavé rozložení úspěšnosti při plnění úkolů. První úkol splnili účastníci v průměru na 60 %, druhý na 50 % a třetí se ukázal jako nejtěžší a byl splněn v průměru na 40 %.

Úkoly na první pohled vypadají složitě a časově náročné. Důvodem není to, že bychom chtěli vyřadit co nejvíce kandidátů. Během studia se studenti potýkají s úkoly z reálného života – chatování, Yandex.Music pro děti nebo Yandex.Weather pro lidi závislé na počasí. K tomu potřebujete výchozí základnu.

Pamatuji si, že jsem před dvěma lety viděl svůj vstupní úkol SRI a myslel jsem si, že ho nikdy nevyřeším. Hlavní v tuto chvíli je sednout si, pečlivě si přečíst podmínky a pustit se do toho. Ukazuje se, že podmínky obsahují téměř 80 % roztoku. Například v podmínce třetího úkolu (nejtěžšího) jsme přidali odkazy na servisní pracovníky a Notifications API na MDN. Studenti, kteří studovali obsah odkazů, jej bez problémů dokončili.

Opravdu bych si přál, aby si tento článek přečetli kandidáti, kteří plánují v budoucnu vstoupit do SRI, kteří nemohli vstoupit do Minské školy nebo kteří začínají dělat jakýkoli jiný testovací úkol. Jak vidíte, je to docela možné. Stačí si věřit a poslouchat všechny tipy od autorů.

Zdroj: www.habr.com

Přidat komentář