Interface ûntwikkeling skoalle: analyze fan taken foar Minsk en in nije set yn Moskou

Hjoed is in nije ynskriuwing iepene Yandex Interface Development School yn Moskou. De earste etappe fan de training sil plakfine fan 7 septimber oant 25 oktober. Studinten út oare stêden kinne dêr op ôfstân of persoanlik oan meidwaan - it bedriuw sil betelje foar reizen en ferbliuw yn in hostel. De twadde, ek de lêste etappe, duorret oant 3 desimber, it kin allinnich persoanlik ôfmakke wurde.

Myn namme is Yulia Seredich, wy skreaunen dizze post tegearre mei Sergei Kazakov. Wy binne beide ynterface-ûntwikkelders yn it Minsk-kantoar fan Yandex en ôfstudearden fan SRI fan eardere jierren.

Interface ûntwikkeling skoalle: analyze fan taken foar Minsk en in nije set yn Moskou

Ta gelegenheid fan de iepening fan registraasje yn Moskou, wy publisearje in analyze fan ynliedende taken oan de foarige Skoalle - hjir yn Minsk.

As jo ​​​​de skiednis fan SRI-opdrachten folgje, hawwe wy fan jier nei jier trije wichtige feardigens testen foar in programmeur:

  • Opmaak. Elke ûntwikkelder moat yndieling kinne dwaan. It bart net dat jo omke Seryozha hawwe dy't ûntwerpt foar it hiele team, en jo skriuwe allinich skripts. Dêrom moat elke studint sjen litte hoe't hy wit hoe te typen.
  • JavaSkript. As de saak beheind wie ta yndieling, dan soene wy ​​gjin School of Interface Development hawwe, mar in School of Layout Designers. De prachtich ûntworpen ynterface moat opnij wurde opnij. Dêrom is der altyd in taak foar JS, mar soms is it ek in taak foar algoritmen - wy hâlde der sa folle fan.
  • Probleemoplossing is faaks de wichtichste feardigens fan in ûntwikkelder. As it giet om it meitsjen fan ynterfaces, dingen feroarje hiel fluch. It is lykas Lewis Carroll: "Jo moatte sa hurd rinne as jo kinne gewoan om op itselde plak te bliuwen, en om nei in oar plak te kommen moatte jo twa kear sa hurd rinne." Elke dei komme wy nije technologyen tsjin - wy moatte har rekken hâlde en kinne se begripe. Dêrom hawwe wy yn 'e tredde taak foarsteld om technologyen te begripen dy't in begjinnende ûntwikkelder normaal net bekend is.

Yn 'e analyze fan elke taak sille wy jo net allinich fertelle oer de juste proseduere, mar ek oer mienskiplike flaters.

Opdracht 1: Portfolio

De earste taak waard wurke troch Yandex.Collections ûntwerper Alexey Cherenkevich, wa wit hoe te dwaan layout, en syn tsjinst kollega, ynterface ûntwikkelder Sergey Samsonov.

Betingst

Meitsje in portfoliowebside: fertel ús oer josels, jo wurk en jo ferwachtings fan 'e Skoalle. De side moat safolle mooglik oerienkomme mei de foarstelde yndieling (keppelings nei layouts: 1000px, 600px, 320px, spesifikaasje). Wy binne allinnich ynteressearre yn de yndieling, dus brûk gjin JavaScript.

By it kontrolearjen sille wy rekken hâlde mei:

  • ynspringgrutte, kleurkorrektheid, lettertypestyl, lettertypegrutte;
  • semantyske yndieling;
  • de oanwêzigens fan ferskate steaten fan eleminten: it werjaan fan knoppen en keppelings as jo mei de rinnerke hingje, aktive ynfierfjilden markearje, ensfh.
  • cross-browser kompatibiliteit (test yn 'e lêste ferzjes fan populêre browsers).

It foardiel sil wêze:

  • gebrûk fan moderne CSS-oplossingen: flexbox, grid, ensfh.
  • Adaptive yndieling;
  • gebrûk fan pre- en (of) post-processors, gearstalling, minifikaasje, optimalisaasje fan útfierkoade;
  • HTML formulier falidaasje, stilisearre triem upload knop.

De taak is frij voluminous, dus jo kinne oerslaan wat net wurket. Dit sil jo skoare in bytsje ferleegje, mar jo sille jo kennis noch kinne demonstrearje. As jo ​​klear binne, stjoer ús twa keppelings - nei jo portfolio en de boarnekoade op GitHub.

De yndielingen foarsteld yn de opdracht wiene net allinnich mei skermen foar mobile apparaten, tablets en buroblêden, mar ek mei echte spesifikaasjes.

Om safolle mooglik objektiviteit yn it resultaat fan it kontrolearjen fan de earste taak te bringen, wiene der in protte kritearia foar dizze kontrôle.

kritearia

Ûntwurpen webside. Dit liket fanselssprekkend, mar guon jonges sloegen wat blokken hielendal oer - of se woene tiid besparje, of se koene se net dwaan. De yndieling kin rûchwei ferdield wurde yn fjouwer haadskermen: it haadskerm mei in avatar, in blok mei in list mei ferwachtings fan SRI, in blok mei in portfolio en in blok mei kontaktynformaasje. Se koenen wurde makke yn seksjes of gewoan mei help fan divs, it wichtichste ding is dat alle fjouwer blokken wiene beskikber.

Konformiteit fan layout mei layout. De ûntwerper makke in aparte spesifikaasje (ynklusyf kleuren, typografy, knopstatus, ensfh.) Om it makliker te meitsjen foar kandidaten. Oan 'e ûnderkant wie d'r in hint oer de ynspringen en funksjes fan it earste skerm. Ik wie tige tefreden oer de jonges dy't rekken holden mei alle winsken fan 'e ûntwerper: bygelyks it earste skerm hie net minder wêze moatten as de hichte fan 'e viewport.

Adaptive yndieling - dit is wannear't de ynterface net allinich is oanlein sadat by trije resolúsjes alles pixel nei pixel is yn yndieling. Yn tuskensteaten moat de yndieling ek net útinoar falle. Guon fergeaten de maksimale breedte fan 'e kontener te beheinen en alles op 1920 piksels te setten, guon fergriepen de eftergrûnen, mar oer it algemien koene de kandidaten dizze taak goed.

Semantyske yndieling. "Hoefolle kearen hawwe se de wrâld ferteld" dat de keppeling moat wurde ûntwurpen as , de knop - as . Gelokkich foldienen de measte kandidaten ek oan dizze eask. Net elkenien erkende de ferburgen list yn 'e ferwachtingen fan' e SRI, wêrtroch't it div-tags brûke, mar it is net sa slim. Der wie in kandidaat dy't alle semantyske tags ynfoege dy't er wist - wêr't it nedich wie en wêr't it net nedich wie. Bygelyks, ynstee fan in list - en . Ommers, semantyk - it giet oer it begripen fan 'e gearstalling fan jo side en it doel fan elk blok (de mearderheid slagge it hjir), en ek it brûken fan pre- en / of post-processors (in pear slagge it hjir, hoewol dit wie ek yn 'e punten - meast brûkten se minder en scss) .

Wurkjende slider. Yn de opdracht skreaunen wy dat JS net brûkt wurde kin. Hjir waard de mooglikheid om problemen op te lossen hifke - in slider koe wurde makke mei in bosk en . Alle magy bart op it selektornivo #button-N:checked ~ .slider-inner .slider-slides. As wy op ien fan 'e ynfierfakjes klikke, giet it yn' e kontrolearre steat. Wy kinne hjirfan profitearje en de oersetting dy't wy nedich binne tawize oan 'e kontener mei de dia's: transform: translate (-33%). Jo kinne de ymplemintaasje fan 'e slider sjen hjir.

Dropdown listen. Hjir kaam it ek allegear op del en in ferlykbere selector: .accordion-item input: checked ~ .accordion-item__content. Jo kinne de ymplemintaasje sjen hjir.

Beskikberens fan :hover, :active en :focu* steaten. In tige wichtich punt. Komfort by ynteraksje mei de ynterface wie derfan ôfhinklik. De brûker moat altyd feedback krije oer har aksjes. Dit item waard kontrolearre yn 'e ynteraksje mei de fragelist. As ik op de knop "Rop my" klikte en der is fisueel neat bard (ek al is it fersyk ferstjoerd), dit is min, want dan sil ik it wer en wer klikke. Dêrtroch wurde tsien oanfragen ferstjoerd en ik sil tsien kear werom belle wurde. Wy moatte net ferjitte dat mobile apparaten gjin mûs hawwe, wat betsjut dat d'r gjin hover moat wêze. En noch ien punt dat gjin ynfloed hat op dejingen dy't it punt oer semantyk foldienen. As jo ​​kontrôle gjin ynteraktyf elemint is, dan as jo der oerhinne hâlde, sil de rinnerke standert bliuwe. It sjocht der hiel untidy, sels as jo hawwe skreaun in reaksje op hover. Net ûnderskatte rinnerke: oanwizer.

Animations. It is wichtich dat alle reaksjes dy't foarkomme mei de eleminten glêd binne. Neat yn it libben is direkt, dus it hawwen fan oergongen op hover en aktyf wie genôch om de ynterface nofliker te meitsjen. No, dejingen dy't de slider en listen animearren binne oer it algemien geweldich.

Mei help fan de nijste technology. In protte minsken brûkten flex, mar gjinien foltôge de taak mei help fan raster. It punt waard teld as flex goed brûkt waard. As earne de yndieling útinoar kaam fanwegen dizze tige flexes, helaas, jo hawwe gjin ekstra punten krigen.

Formuliervalidaasje. Alles wat nedich wie wie it fereaske attribút ta te foegjen oan elke ynfier fan it formulier. Wy hawwe punten tafoege oan dyjingen dy't it e-postfjild as e-post validearre hawwe.

Styling fan de knop foar upload fan bestân. Wy ferwachte in kombinaasje te sjen lykas: en selektearje triem . Dêrnei moasten wy de ynfier ferbergje en it label stylearje. D'r is in oare gewoane manier - om in transparante ynfier te meitsjen en it boppe op 'e knop te pleatsen. Mar net alle browsers tastean styling , en sa'n oplossing kin net folslein cross-browser neamd wurde. En it is semantysk korrekter om in label te meitsjen.

Cross-browser kompatibiliteit. Wy hawwe kontrolearre dat alles goed wie yn 'e twa lêste ferzjes fan moderne browsers (sûnder IE - dielnimmers wiene gelok), lykas yn Safari op iPhones en Chrome op Androids.

Krektoarsom, wy lutsen punten as immen brûkte JS of Bootstrap: beide fan harren soe ferslaan it doel fan de hiele taak. Boppedat krigen dielnimmers mei Bootstrap net allinich in minus, mar ferlearen ek in protte punten foar semantyk en ymplementeare eleminten.

Dejingen dy't har side earne op it ynternet hosten, krigen gjin spesjaal foardiel - mar de resinsinten wiene tige bliid doe't se gjin repositories hoegden te downloaden en lokaal op har kompjûter út te fieren. Dat dit tsjinne as in plus foar karma.

De earste taak wie benammen nuttich foar de studint. Dejingen dy't wy net akseptearje hawwe no in taret CV - jo kinne it mei grutsk heakje oan alle antwurden of pleatse it op jo gh-siden.

Opdracht 2: Ferfier rûte

De skriuwer fan 'e taak is it haad fan' e sykinterfacegroep Denis Balyko.

Betingst

Hawwe jo in stjerkaart? It toant de namme fan elke stjer, lykas de ôfstân derfan nei oare stjerren yn ljochtsekonden. Implementearje de oplossingsfunksje, dy't trije arguminten moat nimme: in objekt wêryn de kaaien de nammen fan 'e stjerren binne, en de wearden binne de ôfstannen nei de stjerren (ienrjochtingsferkear yn 'e romte), lykas de nammen fan de start- en einpunten fan it paad - respektivelik start en finish. De funksje moat de koartste ôfstân fan 'e startstjer werombringe nei de finishstjer en it paad om te folgjen.

Funksje hântekening:

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

Foarbyld fan input data:

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

Foarbyld útfier:

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

Opmerking: It oplossingsskelet is yn 'e src/ map, set jo oplossing yn solution.js.

De ferifikaasje fan 'e twadde taak wie de meast automatisearre en objektyf. De measte jonges rieden dat it nedich wie om it algoritme fan Dijkstra út te fieren. Dejingen dy't syn beskriuwing fûn en it algoritme yn JS ymplementearre binne goed dien. By it kontrolearjen fan de opdracht kamen wy lykwols in protte papieren tsjin mei deselde flaters. Wy sochten op it ynternet foar koadefragminten en fûnen in artikel wêrfan dielnimmers it algoritme kopieare. It is grappich dat in protte minsken de koade út it artikel kopieare tegearre mei de opmerkings fan 'e auteur. Sokke wurken krigen in lege skoare. Wy ferbiede it gebrûk fan alle boarnen net, mar wy wolle dat in persoan ferdjipje yn wat er skriuwt.

kritearia

Foar testen waarden haadpunten takend. Soms wie it dúdlik dat de jonges mei de repository rommele, mappen omneamen, en tests soene mislearje gewoan om't se de nedige bestannen net koene fine. Dit jier hawwe wy besocht sokke jonges te helpen en hawwe alles foar harren op syn plak werombrocht. Mar takom jier we plan te wikseljen ôf nei in wedstriid systeem, en dit sil net mear wurde ferjûn.

D'r wiene ek "minsklike", hânmjittige kritearia. Bygelyks, de oanwêzigens fan in inkele koade styl. Nimmen luts punten foar it brûken fan ljeppers ynstee fan spaasjes of oarsom. It is in oare saak as jo wikselje inkele quotes mei dûbele quotes neffens ien regel dy't jo bekend is, en puntkomma's willekeurich pleatse.

De dúdlikens en lêsberens fan de oplossing waard apart rekken holden. Op alle konferinsjes yn 'e wrâld sizze se dat 80% fan' e baan fan in programmeur bestiet út it lêzen fan koade fan oare minsken. Sels skoalbern ûndergean koade resinsjes - fan harren kurators en fan elkoar. Dat dit kritearium hat signifikant gewicht. D'r wiene wurken wêryn't gjin fariabelen langer wiene as ien karakter - doch dat asjebleaft net. De opmerkingen fan 'e dielnimmers wiene heul bemoedigend - mei útsûndering fan dyjingen dy't identyk wiene oan' e opmerkings fan Stella Chang.

It lêste kritearium is de oanwêzigens fan autotests. Allinich in pear minsken hawwe se tafoege, mar foar elkenien waard it in enoarme plus yn har karma.

Korrekte oplossing:

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

Taak 3: Evenemintenskalinder

It waard taret troch ynterface-ûntwikkelders Sergey Kazakov en Alexander Podskrebkin.

Betingst

Skriuw in mini-kalinder om jo skema wer te jaan. Jo kinne elk skema nimme dat jo wolle. Bygelyks it skema fan frontend-konferinsjes yn 2019.

De kalinder moat lykje as in list. D'r binne gjin oare ûntwerpeasken. Meitsje it mooglik om herinnerings foar eveneminten 3, 7 en 14 dagen yn te stellen. Nei de earste download fan it ynternet moat de kalinder iepenje en offline funksjonearje.

Nuttige boarnen

Skema foar frontend konferinsje:
confs.tech/javascript?topics=javascript%2Bcss%2Bux

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

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

De tredde taak wie de meast nijsgjirrige om te testen, om't der safolle mooglike oplossingen wiene, elk mei har eigen. Wy hawwe kontrolearre hoe't de kandidaat omgiet mei ûnbekende technologyen - oft hy wit hoe te ûndersykjen, oft hy syn oplossingen test.

kritearia

Folde kalinder. Ja, it moast noch útlein wurde. D'r wiene ek dyjingen dy't de betingst te letterlik namen en gjin inkelde rigel CSS-koade ynfoegje. It seach der net sa oantreklik út, mar as alles slagge, foelen de punten net ôf.

In list mei eveneminten krije fan in boarne. Dit is gjin yndielingstaak, dus de list mei eveneminten dy't dêryn opnommen binne, waard net teld. Jo kinne altyd in konferinsje annulearje, opnij plannen of in nije taheakje. Dat it wie nedich om gegevens fan bûten te ûntfangen en de yndieling te meitsjen basearre op de ûntfongen JSON. It wie wichtich om de gegevens op ien of oare manier te krijen (mei de fetch-metoade of mei help fan XMLHttpRequest). As in persoan in polyfill tafoege foar opheljen en syn kar markearre yn 'e readme, waard dit as in plus rekkene.

Registraasje fan tsjinstarbeiders sûnder flaters en wurkje offline nei de earste download. Hjir is in foarbyld tsjinst arbeider mei skema caching op earste boot. Details oer tsjinstmeiwurkers, har mooglikheden en manieren om mei har te wurkjen (strategyen foar wurkjen mei caches, wurkje offline) kinne jo hjir fine.

Mooglikheid om in herinnering yn te stellensadat it eins wurket nei 3, 7, 14 dagen. It wie nedich om de notifikaasjes API te begripen, link nei hokker wie rjocht op taak. Wy ferwachten gjin spesifike ymplemintaasje om te kontrolearjen oft it tiid is om te drukken. Elke wurkopsje waard akseptearre: opslach yn localStorage, IndexDB of periodike polling troch in tsjinstmeiwurker. It wie sels mooglik om in push-tsjinner te meitsjen (hjir foarbyld), mar it soe net offline wurkje. It wie like wichtich om in druk te ûntfangen nei't de side sluten wie - en nei in skoft iepene. As de herinnering stoar tagelyk de side waard sletten, de oplossing waard net teld. It is cool doe't de jonges neitinke oer de resinsinten en it mooglik makken om no in druk te krijen - om net 3 dagen te wachtsjen.

Mooglikheid om in ikoan op it buroblêd te pleatsen (PWA). Wy hawwe de oanwêzigens fan it bestân kontrolearre manifest.json mei de juste ikoanen. Guon jonges makken dit bestân (of lieten it generearje yn CreateReactApp) - mar hawwe de juste ikoanen net tafoege. Dan, as jo besykje te ynstallearjen, barde in flater lykas "in oar byldkaike is nedich".

Codestyle en projektstruktuer. Lykas yn 'e twadde taak, hawwe wy sjoen nei ien koadestyl (ek as it net oerienkomt mei ús). Guon jonges geschroefd op linters - dat is geweldich.

Konsole flaters. As d'r in yndikator rjochts yn 'e konsole wie dat der wat mis wie, en de dielnimmer hat der gjin omtinken oan, dan hawwe wy punten ôfrekkene.

Resultaten

Wat grappich is oan de besluten fan de dielnimmers:

  • Ien fragelist befette de folgjende tekst: “In programmeurfreon holp my in React-applikaasje gear te setten. Ik bombardearre him mei fragen oer hoe en wêrom, en hy fertelde my. Ik fûn it tige leuk, ik wol der mear oer witte.” Wy wiene mei ús hiele hert oan it rootjen fan dizze applikaasje, mar spitigernôch wie de freon fan 'e kandidaat net heul nuttich om de applikaasje te wurkjen.
  • Ien kandidaat stjoerde in keppeling nei GitHub, wêr't it RAR-argyf siet - it is lestich om hjirop kommentaar te jaan. 🙂
  • In oare kandidaat, yn 'e opmerking op' e earste line fan 'e solution.js-bestân, joech earlik ta dat hy it algoritme kopiearre.

Wy krigen oanfragen fan 76 kandidaten en selekteare 23 minsken. Wy krigen fragelisten net allinnich út Minsk, mar ek út Moskou, Sint-Petersburch en sels Tatarstan. Guon fan 'e jonges ferrasten ús mei har hjoeddeistige beroppen: ien fan har is in forensyske ekspert, en de oare is in medyske studint.

It resultaat wie in nijsgjirrige ferdieling fan súksesraten by it foltôgjen fan taken. De dielnimmers foltôge de earste taak mei gemiddeld 60%, de twadde mei 50%, en de tredde wie it dreechste en waard foltôge mei in gemiddelde fan 40%.

Op it earste each sjogge de taken kompleks en tiidslinend. De reden is net dat wy safolle mooglik kandidaten weihelje wolle. Tidens harren stúdzje wurde studinten konfrontearre mei echte taken - in petear meitsje, Yandex.Music foar bern of Yandex.Weather foar waarôfhinklike minsken. Hjirfoar hawwe jo in startbasis nedich.

Ik herinner my dat ik myn SRI-yngongstaak twa jier lyn seach en tocht dat ik it noait soe oplosse. It wichtichste ding op dit stuit is om te sitten, de betingsten foarsichtich te lêzen en it te begjinnen. It docht bliken dat de betingsten befetsje hast 80% fan de oplossing. Bygelyks, yn 'e tastân fan' e tredde taak (de dreechste), hawwe wy keppelings tafoege oan tsjinstarbeiders en Notifikaasjes API op MDN. Learlingen dy't de ynhâld fan 'e keppelings studearre hawwe it sûnder muoite foltôge.

Ik soe wirklik graach wolle dat dit artikel wurdt lêzen troch kandidaten dy't fan plan binne om yn 'e takomst SRI yn te gean, dy't de Minsk Skoalle net koene yngean, of dy't begjinne mei in oare testtaak. Sa't jo sjen kinne, is it hiel mooglik om te dwaan. Jo moatte gewoan yn josels leauwe en harkje nei alle tips fan 'e auteurs.

Boarne: www.habr.com

Add a comment