Liidese arenduskool: Minski ülesannete analüüs ja uus komplekt Moskvas

Täna avati uus registreerimine Yandexi liidese arenduskool Moskvas. Koolituse esimene etapp toimub 7. septembrist 25. oktoobrini. Teiste linnade tudengid saavad selles osaleda kaugjuhtimise teel või isiklikult – ettevõte tasub reisi ja majutuse hostelis. Teine, ühtlasi ka viimane etapp, kestab 3. detsembrini, selle saab läbida vaid isiklikult.

Minu nimi on Julia Seredich, kirjutasime selle postituse koos Sergei Kazakoviga. Oleme nii liidese arendajad Yandexi Minski kontoris kui ka eelmistel aastatel SRI lõpetanud.

Moskvas registreerimise avamise puhul avaldame eelmise Kooli – siin Minskis – sissejuhatavate ülesannete analüüsi.

Kui jälgida SRI ülesannete ajalugu, testisime aastast aastasse kolme olulist programmeerija oskust:

• Paigutus. Iga arendaja peaks suutma küljendust teha. Ei juhtu, et teil on onu Serjoža, kes kujundab kogu meeskonnale, ja teie kirjutate ainult stsenaariume. Seetõttu peab iga õpilane näitama, kuidas ta oskab laduda.
• JavaScript. Kui asi piirduks küljendusega, siis ei oleks meil mitte liidesearenduse, vaid küljendajate kool. Kaunilt kujundatud liides vajab taaselustamist. Seetõttu on JS-i jaoks alati ülesanne, kuid mõnikord on see ülesanne ka algoritmide jaoks - me armastame neid nii väga.
• Probleemide lahendamine on ehk arendaja kõige olulisem oskus. Liideste loomisel muutuvad asjad väga kiiresti. See on nagu Lewis Carroll: "Sa pead jooksma nii kiiresti kui võimalik, et püsida samas kohas, ja teise kohta jõudmiseks peate jooksma kaks korda kiiremini." Iga päev puutume kokku uute tehnoloogiatega – peame nendega arvestama ja oskama neist aru saada. Seetõttu tegime kolmandas ülesandes ettepaneku mõista tehnoloogiaid, mida algaja arendaja tavaliselt ei tunne.

Iga ülesande analüüsis räägime teile mitte ainult õigest protseduurist, vaid ka levinud vigadest.

Ülesanne 1: Portfoolio

Esimese ülesande kallal töötasid Yandex.Collections disainer Aleksei Tšerenkevitš, kes teab, kuidas küljendust teha, ja tema teeninduskolleeg, liidese arendaja Sergei Samsonov.

Seisund

Looge portfoolio veebisait: rääkige meile endast, oma tööst ja ootustest koolile. Sait peaks võimalikult suurel määral vastama pakutud paigutusele (lingid paigutustele: 1000px, 600px, 320px, spetsifikatsioon). Meid huvitab ainult paigutus, seega ärge kasutage JavaScripti.

Kontrollimisel võtame arvesse:

• taande suurused, värvide korrektsus, kirjastiil, fondi suurus;
• semantiline paigutus;
• elementide erinevate olekute olemasolu: nuppude ja linkide kuvamine kursori hõljutamisel, aktiivsete sisestusväljade esiletõstmine jne;
• brauseritevaheline ühilduvus (testitud populaarsete brauserite uusimates versioonides).

Eelis saab olema:

• kaasaegsete CSS-lahenduste kasutamine: flexbox, grid jne;
• Adaptiivne paigutus;
• eel- ja (või) järelprotsessorite kasutamine, komplekteerimine, minimeerimine, väljundkoodi optimeerimine;
• HTML-vormingu kinnitamine, stiliseeritud faili üleslaadimise nupp.

Ülesanne on üsna mahukas, nii et võite vahele jätta selle, mis ei tööta. See vähendab teie skoori pisut, kuid saate siiski oma teadmisi näidata. Kui olete lõpetanud, saatke meile kaks linki – oma portfelli ja GitHubi lähtekoodi juurde.

Ülesandes pakutud paigutused ei sisaldanud ainult mobiilseadmete, tahvelarvutite ja lauaarvutite ekraane, vaid ka tegelikke tehnilisi andmeid.

Selleks, et tuua esimese ülesande kontrollimise tulemusse võimalikult palju objektiivsust, oli selle kontrolli jaoks palju kriteeriume.

kriteeriumid

Disainitud veebisait. See tundub ilmselge, kuid mõned poisid jätsid mõned plokid täiesti vahele – kas nad tahtsid aega säästa või ei saanud seda teha. Paigutuse võib laias laastus jagada neljaks põhiekraaniks: avatariga põhiekraan, SRI ootuste loendiga plokk, portfelliga plokk ja kontaktandmetega plokk. Neid sai teha sektsioonide kaupa või lihtsalt dive kasutades, peaasi, et kõik neli plokki olemas olid.

Paigutuse vastavus paigutusele. Disainer tegi eraldi spetsifikatsiooni (sh värvid, tüpograafia, nuppude olekud jne), et kandidaatidel oleks lihtsam. Allosas oli vihje esimese ekraani taande ja funktsioonide kohta. Jäin väga rahule kuttidega, kes võtsid arvesse kõiki disaineri soove: näiteks ei oleks esimene ekraan tohtinud olla väiksem kui vaateava kõrgus.

Adaptiivne paigutus - see on siis, kui liides ei ole lihtsalt paigutatud nii, et kolme eraldusvõime korral on paigutuses kõik pikslit piksliteni. Vaheolekutes ei tohiks ka paigutus laguneda. Mõni unustas konteineri maksimaalset laiust piirata ja seadis kõik 1920 pikslile, mõni ajas taustad sassi, kuid üldiselt said kandidaadid selle ülesandega hästi hakkama.

Semantiline paigutus. "Mitu korda nad on maailmale öelnud", et link tuleks kujundada kui , nupp - kui . Õnneks täitis enamik kandidaate ka selle nõude. Mitte igaüks ei tundnud SRI ootustes peidetud loendit, tehes selle div-siltide abil, kuid see pole nii hull. Oli kandidaat, kes pani kõik semantilised sildid, mida ta teadis – kuhu vaja ja kuhu mitte. Näiteks loendi asemel - ja . Lõppude lõpuks, semantika - see on teie lehe koostise ja iga ploki eesmärgi mõistmine (enamik sai sellega hakkama siin), samuti eel- ja/või järelprotsessorite kasutamine (mõned said sellega hakkama, kuigi see oli ka punktides - enamasti kasutati vähem ja scss) .

Töötav liugur. Ülesandes kirjutasime, et JS-i kasutada ei saa. Siin testiti ülesannete lahendamise oskust – liugurit sai teha kasutades kombinatsiooni ja . Kogu maagia toimub valija tasemel #button-N:checked ~ .slider-inner .slider-slides. Kui klõpsame ühel sisendi märkeruudul, läheb see märgistatud olekusse. Saame seda ära kasutada ja määrata vajaliku tõlke konteinerile koos slaididega: transform: translate (-33%). Näete liuguri rakendamist siin.

Rippmenüüd. Siin taandus kõik ka ja sarnasele valijale: .accordion-item input:checked ~ .accordion-item__content. Saate näha teostust siin.

Olekute :hover, :active ja :focu* saadavus. Väga oluline punkt. Sellest sõltus mugavus liidesega suhtlemisel. Kasutaja peaks oma tegevuse kohta alati tagasisidet saama. Seda üksust kontrolliti kogu küsimustikuga suhtlemise ajal. Kui vajutasin nuppu “Helista mulle” ja visuaalselt ei juhtunud midagi (kuigi päring saadeti), on see halb, sest siis klõpsan seda ikka ja jälle. Selle tulemusena saadetakse kümme päringut ja mulle helistatakse kümme korda tagasi. Me ei tohi unustada, et mobiilseadmetel pole hiirt, mis tähendab, et hõljumist ei tohiks olla. Ja veel üks punkt, mis ei mõjutanud neid, kes täitsid semantika punkti. Kui teie juhtelement ei ole interaktiivne element, jääb kursor selle kohale hõljutades standardseks. See näeb väga korrastamata välja, isegi kui olete kirjutanud reaktsiooni hõljumisele. Ärge alahinnake kursorit: kursor.

Animatsioonid. On oluline, et kõik elementidega toimuvad reaktsioonid oleksid sujuvad. Miski elus ei toimu silmapilkselt, nii et liidese meeldivamaks muutmiseks piisas hõljukil ja aktiivsest üleminekust. Noh, need, kes animeerisid liugurit ja loendeid, on üldiselt suurepärased.

Kasutades uusimat tehnoloogiat. Paljud inimesed kasutasid flexi, kuid keegi ei täitnud ülesannet ruudustiku abil. Punkt läks arvesse, kui flexi kasutati õigesti. Kui kuskil läks paigutus nende väga painde tõttu laiali, siis paraku ei saanud te lisapunkte.

Vormi kinnitamine. Kõik, mida oli vaja, oli lisada nõutav atribuut igale vormi sisendile. Lisasime punkte neile, kes kinnitasid meilivälja meiliks.

Faili üleslaadimisnupu stiil. Ootasime sellist kombinatsiooni nagu: ja Valige fail. Järgmisena pidime sisendi peitma ja sildi stiilima. On veel üks levinud viis – teha läbipaistev sisend ja panna see nupu peale. Kuid mitte kõik brauserid ei võimalda stiilimist ja seda lahendust ei saa nimetada täielikult brauseritevaheliseks. Ja semantiliselt õigem on sildi tegemine.

Brauseriülene ühilduvus. Kontrollisime, et kõik oleks korras nii moodsate brauserite kahes uusimas versioonis (ilma IEta – osalejatel vedas), samuti iPhone'i Safaris ja Androidi Chrome'is.

Vastupidi, võtsime punktid maha, kui keegi kasutas JS-i või Bootstrapi: mõlemad kaotaksid kogu ülesande eesmärgi. Veelgi enam, Bootstrapiga osalejad ei saanud mitte ainult miinust, vaid kaotasid ka palju punkte semantika ja rakendatud elementide eest.

Need, kes majutasid oma saiti kuskil Internetis, ei saanud erilist eelist - kuid arvustajad olid väga õnnelikud, kui nad ei pidanud hoidlaid alla laadima ja neid oma arvutis kohapeal käivitama. Nii et see oli karma pluss.

Esimene ülesanne oli väga kasulik eelkõige õpilasele. Neil, keda me vastu ei võtnud, on nüüd valmis CV - saate selle uhkusega lisada kõikidele vastustele või postitada oma gh-lehtedele.

Ülesanne 2: Transporditee

Ülesande autor on otsinguliideste grupi juht Denis Balyko.

Seisund

Kas teil on tähekaart? See näitab iga tähe nime ja kaugust sellest teiste tähtedeni valgussekundites. Rakendage lahendusfunktsioon, mis peaks sisaldama kolme argumenti: objekt, mille võtmeteks on tähtede nimed ja väärtusteks on kaugused tähtedeni (ühesuunaline liiklus ruumis), samuti objektide nimed. raja algus- ja lõpp-punktid – vastavalt algus ja finiš. Funktsioon peaks tagastama kõige lühema vahemaa starditähest finišitäheni ja jälgitava tee.

Funktsiooni allkiri:

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

Sisendandmete näide:

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

Näidisväljund:

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

Märkus. Lahenduse skelett on kaustas src/, asetage lahendus kausta Solution.js.

Teise ülesande kontrollimine oli kõige automatiseeritum ja objektiivsem. Enamik poisse arvas, et on vaja Dijkstra algoritmi rakendada. Need, kes selle kirjelduse leidsid ja JS-is algoritmi juurutasid, on hästi hakkama saanud. Ülesannet kontrollides sattusime aga paljude samade vigadega paberitele. Otsisime Internetist koodifragmente ja leidsime artikli, millest osalejad algoritmi kopeerisid. Naljakas, et paljud inimesed kopeerisid artikli koodi koos autori kommentaaridega. Sellised tööd said madala hinde. Me ei keela mingite allikate kasutamist, aga tahame, et inimene süveneks sellesse, mida ta kirjutab.

kriteeriumid

Testide eest anti põhipunkte. Mõnikord oli selge, et poisid ajasid hoidlaga segamini, nimetasid kaustu ümber ja testid ebaõnnestusid lihtsalt seetõttu, et nad ei leidnud vajalikke faile. Sel aastal püüdsime selliseid mehi aidata ja andsime neile kõik oma kohale tagasi. Kuid järgmisel aastal plaanime minna üle võistlussüsteemile ja seda enam ei andestata.

Olid ka “inimlikud”, manuaalsed kriteeriumid. Näiteks ühe koodistiili olemasolu. Keegi ei võtnud punkte maha tabeldusmärkide kasutamise eest tühikute asemel või vastupidi. Teine asi on see, kui vahetate üksikjutumärke topeltjutumärkidega ühe teile teadaoleva reegli järgi ja asetate semikoolonid juhuslikult.

Eraldi võeti arvesse lahenduse selgust ja loetavust. Kõigil maailma konverentsidel öeldakse, et 80% programmeerija tööst koosneb teiste inimeste koodide lugemisest. Isegi koolilapsed läbivad koodiülevaatusi – nii kuraatoritelt kui ka üksteiselt. Seega oli sellel kriteeriumil märkimisväärne kaal. On olnud töid, milles polnud ühest märgist pikemaid muutujaid – palun ärge tehke seda. Osalejate kommentaarid olid väga julgustavad – välja arvatud need, mis olid identsed Stella Changi kommentaaridega.

Viimane kriteerium on automaattestide olemasolu. Ainult mõned inimesed lisasid neid, kuid kõigi jaoks sai see tohutuks plussiks nende karmas.

Õige lahendus:

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

Ülesanne 3: Sündmuste kalender

Selle koostasid liidese arendajad Sergei Kazakov ja Aleksander Podskrebkin.

Seisund

Kirjutage oma ajakava kuvamiseks minikalender. Võite võtta mis tahes ajakava, mis teile meeldib. Näiteks 2019. aasta frontend konverentside ajakava.

Kalender peaks välja nägema loendina. Muid disaininõudeid pole. Võimaldab määrata sündmuste meeldetuletusi 3, 7 ja 14 päeva ette. Pärast esimest Internetist allalaadimist peaks kalender avanema ja töötama võrguühenduseta.

Kasulikud ressursid

Frontendi konverentsi ajakava:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

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

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

Kolmas ülesanne oli kõige huvitavam testida, sest võimalikke lahendusi oli nii palju, igaühel oma. Kontrollisime, kuidas kandidaat võõraste tehnoloogiatega hakkama saab – kas ta oskab uurida, kas ta testib oma lahendusi.

kriteeriumid

Volditud kalender. Jah, see oli ikka vaja paika panna. Oli ka neid, kes võtsid tingimust liiga sõna-sõnalt ega sisestanud ühtegi rida CSS-koodi. See ei tundunud eriti atraktiivne, kuid kui kõik töötas, siis punktid ei vähenenud.

Sündmuste loendi hankimine allikast. See ei ole küljendusülesanne, mistõttu selles sisalduvate sündmuste loendit ei arvestatud. Saate alati konverentsi tühistada, ajastada ümber või lisada uue. Seega oli vaja andmeid väljastpoolt vastu võtta ja saadud JSON-i põhjal kujundus renderdada. Oluline oli hankida andmeid mis tahes viisil (kasutades toomismeetodit või kasutades XMLHttpRequest). Kui inimene lisas toomiseks polüfilli ja märkis oma valiku readme-s, arvestati see plussina.

Teenindaja registreerimine ilma vigadeta ja töötage pärast esimest allalaadimist võrguühenduseta. Siin on näide. teenindustöötaja ajakava vahemällu salvestamisega esimesel käivitamisel. Üksikasjad teenindustöötajate, nende võimaluste ja nendega töötamise viiside kohta (vahemäludega töötamise strateegiad, võrguühenduseta töötamise strateegiad) leiate siit.

Võimalus määrata meeldetuletusnii et see tegelikult toimib 3, 7, 14 päeva pärast. Teavituste API-st oli vaja aru saada, link millele oli ülesandega õige. Me ei oodanud mingit konkreetset rakendamist, et kontrollida, kas on aeg edasi lükata. Nõustuti kõik töövõimalused: salvestamine kohalikus salvestusruumis, IndexDB või teenindustöötaja perioodiline küsitlus. Isegi push-serverit oli võimalik teha (siin näide), kuid see ei töötaks võrguühenduseta. Sama oluline oli saada tõuge pärast lehe sulgemist ja mõne aja pärast avamist. Kui meeldetuletus suri samal ajal, kui leht suleti, siis lahendust ei arvestatud. See on lahe, kui poisid mõtlesid arvustajatele ja võimaldasid kohe tõuke saada - et mitte oodata 3 päeva.

Võimalus paigutada ikooni töölauale (PWA). Kontrollisime faili olemasolu manifest.json õigete ikoonidega. Mõned poisid tegid selle faili (või jätsid selle CreateReactAppi genereerima), kuid ei lisanud õigeid ikoone. Seejärel ilmnes installimisel selline tõrge nagu "vaja on teistsugust ikooni".

Koodistiil ja projekti struktuur. Nagu ka teises ülesandes, vaatasime ühte koodistiili (isegi kui see meie omaga ei ühtinud). Mõned tüübid keerasid linterid külge – see on suurepärane.

Konsooli vead. Kui konsoolis oli indikaator, et midagi on valesti, ja osaleja ei pööranud sellele tähelepanu, siis võtsime punktid maha.

Tulemused

Mis on naljakat osalejate otsustes:

• Üks küsimustik sisaldas järgmist teksti: „Programmeerijast sõber aitas mul Reacti rakenduse kokku panna. Ma pommitasin teda küsimustega, kuidas ja miks, ja ta ütles mulle. Mulle väga meeldis, ma tahan sellest rohkem teada. Me juurdlesime selle avalduse poole kogu hingest, kuid kahjuks ei olnud kandidaadi sõber väga abiks kandideerimise toimimiseks.
• Üks kandidaat saatis lingi GitHubile, kus asus RAR-i arhiiv – seda on raske kommenteerida. 🙂
• Teine kandidaat tunnistas lahendus.js faili esimese rea kommentaaris ausalt, et kopeeris algoritmi.

Avaldusi laekus 76 kandidaadilt ja valisime välja 23 inimest. Meile saadeti küsimustikud mitte ainult Minskist, vaid ka Moskvast, Peterburist ja isegi Tatarstanist. Mõned poisid üllatasid meid oma praeguste ametitega: üks neist on kohtuekspert, teine ​​aga arstitudeng.

Tulemuseks oli ülesannete täitmise edukuse määrade huvitav jaotus. Esimese ülesande täitsid osalejad keskmiselt 60%, teise 50% ja kolmas osutus kõige raskemaks ja täitus keskmiselt 40%.

Esmapilgul tunduvad ülesanded keerulised ja aeganõudvad. Põhjus pole selles, et me tahaks võimalikult palju kandidaate välja rookida. Õpingute ajal seisavad üliõpilased silmitsi päriselu ülesannetega – vestluse tegemine, Yandex.Music lastele või Yandex.Weather ilmast sõltuvatele inimestele. Selleks vajate algbaasi.

Mäletan, et nägin kaks aastat tagasi oma SRI sisseastumisülesannet ja mõtlesin, et ma ei lahenda seda kunagi. Peaasi on sel hetkel maha istuda, tingimused hoolikalt läbi lugeda ja tegema hakata. Selgub, et tingimused sisaldavad peaaegu 80% lahusest. Näiteks kolmanda ülesande (kõige keerulisema) tingimusel lisasime MDN-is lingid teenindustöötajatele ja teavituste API-le. Linkide sisu uurinud õpilased täitsid selle raskusteta.

Tahaksin väga, et seda artiklit loeksid kandidaadid, kes plaanivad tulevikus SRI-sse astuda, kes ei saanud Minski kooli astuda või kes hakkavad täitma mõnda muud testtööd. Nagu näete, on see täiesti võimalik. Peate lihtsalt endasse uskuma ja kuulama kõiki autorite nõuandeid.

Allikas: www.habr.com